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Description 

NOTICE REGARDING COPYRIGHTS 

A portion of the disclosure of this patent document 
contains material which is subject to copyright protec- 
tion. The copyright owner has no objection to the fac- 
simile reproduction by anyone of the patent disclosure, 
as it appears in the Patent and Trademark Office patent 
files or records, but otherwise reserves all copyright 
rights whatsoever. 

FIELD OF THE INVENTION 

This invention relates generally to billing systems, 
and more particularly to systems for processing and dis- 
playing, under the control of a service customer, usage 
and cost information for services rendered to a customer 
by a service provider such as a telecommunications 
company, credit card company, or the like. 

The invention relates particularly to systems for 
processing and displaying, under the control of a tele- 
communications service customer, usage and cost in- 
formation for telecommunications services rendered to 
the customer by a telecommunications service provider, 
and to systems for providing telecommunications billing 
information in a form compatible with popularly available 
personal computers and popularly available personal 
computer operating systems and database manage- 
ment programs to permit selection, processing and dis- 
play of usage and cost information under control of the 
telecommunications customer 

BACKGROUND OF THE INVENTION 

Telecommunications costs have become a major 
expense for many large businesses and other organi- 
zations. Today's competitive business climate requires 
immediate communications between components of an 
organization and between the organization and its sup- 
pliers and customers. This need alone has produced 
over the last twenty years a dramatic increase in the use 
of traditional telecommunications services such as ordi- 
nary switched telephone service, leased-line telephone 
service and telex, typically provided by wireline common 
carriers. In addition, many non-traditional modes of 
electronic communications, such as facsimile and a va- 
riety of computer networking schemes use, as a trans- 
mission medium, either traditional or new telecommuni- 
cations services offered by wireline carriers. 

Organizations are under great pressure to reduce 
telecommunications costs while continuing to make 
available to their personnel and correspondents tele- 
communications services of acceptable quality and 
quantity. In order to minimize costs, attention is increas- 
ingly focused on analysis and processing of call-detail 
records to discover waste, unauthorized use, and sav- 
ings opportunities which may arise from more efficient 



selection of carrier facilities. 

For example, lengthy calls from a particular station 
may indicate inappropriate or inefficient use of the tele- 
phone by authorized personnel. A large number of calls 

5 to a particular geographical region may indicate that 
leased lines or tie-lines are economically justified. Since 
many telecommunications services are priced on a dis- 
tance- and time-of -day-sensitive basis, and since sev- 
eral telecommunications carriers provide differing call- 

10 tng and volume discount plans, customers may avail 
themselves of additional savings opportunities by ap- 
propriately routing traffic over the lowest cost facilities 
and by contracting for special discounts based on usage 
information obtained from such analyses. A further re- 

15 quirement for call-detail record processing is to permit 
large organizations to pass along telecommunications 
charges to the originating department or other internal 
unit. 

Such analysis and processing is hampered, be- 

20 cause even large-volume telecommunications custom- 
ers typically now receive a paper bill itemizing long-dis- 
tance calls and other telecommunications charges by 
originating station. This paper bill is often the exclusive 
means by which the customer may obtain detailed in- 

25 formation concerning telephone calls and other trans- 
actions from which charges arise. Further analysis is 
usually not provided by the carrier. 

In order to process and analyze call-detail informa- 
tion on their own, customers have adopted a variety of 

50 techniques, but each of these has significant disadvan- 
tages. The information on a bill may be analyzed using 
non-automated methods, but these methods are not 
feasible for targe customers, and even for the smallest 
customers are extremely expensive and error-prone. 

35 Since automated processing is preferred, some custom- 
ers manually key-punch or machine-scan the paper bill 
into a computer system. While this approach somewhat 
reduces the cost of the analysis, the data entry steps 
remain expensive and error-prone. 

*o Other customers may receive from the carrier a ma- 
chine-readable tape containing call-detail records, but 
to the inventors' knowledge these tapes either carry un- 
rated call information (i.e. the records do not include the 
cost of the call) or lack certain rating details without 

45 which it is impossible to exactly reconcile information on 
the tape with the paper bill. In addition, the type of tape 
media used, and the manner in which the information is 
organized on such tapes, require that an expensive 
mainframe-class computer be used to analyze the data. 

50 Apparatus has also been developed which may be 
continuously connected to each outgoing station, tele- 
phone line or similar facility used by the customer and 
which records certain details concerning every outgoing 
transaction or call made over that facility The records 

55 thereby produced may then be processed by a compu- 
ter so apply an appropriate rating algorithm and arrive, 
at an approximate cost for each transaction. However, 
since the customer's recording equipment is not identi- 
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cal to the equipment used by the carrier to acquire call- 
detail records, some discrepancies are virtually sure to 
occur, and these discrepancies will be propagated to the 
final results of the analysis. In addition, since the carri- 
ers calling plans and tariffs may change frequently, a 
great deal of effort is required on the part of the customer 
to maintain up-to-date and otherwise accurate rating al- 
gorithms for processing the records. 

Accordingly, the need exists for a system which pro- 
vides to large-volume telecommunications customers 
the ability to conveniently and affordably analyze and 
manipulate call-detail and other telecommunications 
transaction information by computer, and which pro- 
vides results which exactly correspond with the informa- 
tion printed on the customer's paper bill. 

As most relevant prior art, GTE Automatic Electric 
Worldwide Communications Journal, Vol. 21, No. 2, 
1 983, includes an article entitled "An Integrated System 
Approach for Usage Sensitive Service", by D. Mazzola, 
which describes a system for accumulating telephone 
subscriber information concerning services that a carri- 
er provides for a subscriber including all the call infor- 
mation of the telephone carrier subscribers including ac- 
counting data as to the number and duration of local 
calls made, toll calls, the station from which the call was 
made, the location to which the call was sent, etc. This 
accumulated data is then sent on to a primary account- 
ing computer in the system where all the subscriber in- 
formation is collected and subscriber bills are prepared. 

GB-A-20 70 829 discloses a system for preparing 
bills for customers of utility meters. Utility meter data is 
assimilated at the meter locations by accumulating cus- 
tomer profile information for a plurality of meter custom- 
ers on a base computer and transmitting said informa- 
tion via modem to a portable computer at the respective 
location. The portable computer is adapted to visually 
present this information for the respective customer. Af- 
terwards, the new meter reading is imposed into the 
portable computer which calculates the charge for utility 
usage and prints a bill for the meter customer at the site 
of the meter based upon that calculation. The updated 
customer profile information is stored for later transmis- 
sion to the base computer. 

Both prior art systems discussed above obviously 
do not give telecommunications customers the ability to 
readily analyze call-details and other telecommunica- 
tions transaction information at their end, as utilizing 
both systems, the customer just gets a bill with more or 
less detailed billing information. 

SUMMARY OF THE INVENTION 

The present invention according to claims 1 and 4 
provides a system and a method for preprocessing of 
data which has already been processed by a carrier 
(such as the data collected by the techniques described 
in the GTE article) to produce detailed billing analyses 
in the form of summary reports for storage, manipulation 



and display on a subscriber's personal computer. Then, 
these summary reports are utilized for expediting re- 
trieval of data so that the subscriber's personal compu- 
ter can further process the data previously collected by 
s the carrier to enable the personal computer to present 
subsets of the collected data as individually selected by 
the subscriber. 

To highlight the difference between the invention 
and the prior art, it is to be emphasized that the produc- 
ts tion of summary reports from the data provided by the 
carrier is the core of the invention, wherein the preproc- 
essing starts after all of the subscriber information has 
already been accumulated and a bill has been pro- 
duced. Thus, preprocessing and producing summary 
'5 reports in the present invention applies to the handling 
of data at a different and later stage of the e.g. telephone 
carrier's billing process than is contemplated by the GTE 
article of D. Mazzota. In this connection, this prior art 
teaches to carry out accounting preprocessing internally 
20 at the service provider to produce the subscriber bill and 
does not provide the subscriber with any capability of 
manipulating that information or the ability to produce e. 
g. any type of preprocessed graphs, charts or other val- 
uable financial information therefrom, which can be de- 
2S rived by providing preprocessed summary reports by 
the service provider to the subscriber, who can utilize 
these summary reports for aforesaid purposes. This 
means that opposite to the prior art there exists the pos- 
sibility for the subscriber or customer of the service pro- 
30 vider to perform additional processing of e.g. telephone 
data. 

Further advantages of the present invention versus 
prior art are to be cited: 

35 - The subscriber is not obligated to purchase and 
maintain a mainframe computer to process data 
supplied by the carrier in order to obtain the desired 
subset of carrier-collected data. 

^0 - The subscriber can retrieve customized subsets of 
data as required on a personal computer without 
undue processing delays. 

The subscriber can manipulate data on a personal 
*5 computer to create and present desired subsets of 
selected records on demand. 

In the case of a telephone billing system, the sub- 
scriber can achieve the above-noted objectives of 
so conveniently and affordably analyzing and manipu- 
lating call-details and other telecommunications 
transaction information on a personal computer and 
presenting results which exactly correspond with 
the information on the subscriber's data bill. 

55 

This invention contemplates a system combining 
standard data processing hardware and specialty de- 
signed software for distributing to large-volume tele- 
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communications or other service customers telephone 
bills, credit card bills, and the like on diskettes compat- 
ible with commonly available small and inexpensive per- 
sonal computers for customer-directed display and in- 
depth analysis. In brief, telecommunications or other 
service customers wishing to receive a diskette tele- 
phone or credit card bill subscribe for this service with 
their carrier or credit card company. A participating tel- 
ecommunications carrier or credit card company (more 
generally: a 'service provider," or simply 'provider') ex- 
tracts from its data processing facilities appropriately se- 
lected billing information for such subscriber. The pro- 
vider then supplies this information to a "processor", 
who, according to the invention, segregates the billing 
data by subscriber, appropriately p reprocesses the bill- 
ing data to produce a variety of in-depth billing analyses 
in the form of graphs and summary reports, and reor- 
ganizes both raw and analyzed billing data into an opti- 
mal format for storage, manipulation, and display on 
commonly-available personal computers. The "proces- 
sor" writes this information onto one or more diskettes 
compatible with the subscriber's personal computer, 
and distributes these diskettes to the subscriber. The 
subscriber, using an inexpensive personal computer 
and compatible software according to the invention, can 
display and analyze the telephone bill with greater effi- 
ciency, accuracy and flexibility than possible using the 
conventional paper bill. By appropriately selecting the 
billing information obtained from the service provider, 
the invention provides a telephone, credit card or other 
bill on diskette which is exactly reconciled with the paper 
bill. 

One aspect of the invention includes an application 
software package, capable of running on a small com- 
puter (such as an IBM Personal Computer or compatible 
computer), which under the direction of the user can: 

1 . display the telephone bill (or selected subsets 
thereof) in its ordinary (paper-like) format; 

2. display the bill (or selected subsets thereof) sort- 
ed in non-conventional order (e.g. call detail records 
sorted by length of call); 

3. display a variety of preprocessed summary re- 
ports and graphs useful in analyzing telecommuni- 
cations costs; and 

4. display non-preprccessed reports according to 
user-formulated ad-hoc queries. 

The information listed above may also be printed or 
written to a disk file in the user's computer for further 
processing by other software, such as a commercially 
available database management program which runs 
on an IBM-compatible personal computer. Information 
displayed by the inventive customer software is exactly 
reconciled with that printed on the customer's paper bill 
through means described below. 

■ Another aspect of the invention involves the use of 
appropriate method steps and apparatus and control 



software for obtaining appropriate billing information 
from carriers and physically rearranging this information 
in such a manner that it is optimally pre-processed and 
reformatted into a form appropriate for efficient and rap- 
5 id use in subscribers' personal computers, and writing 
the information in this format on compatible diskettes 
containing for distribution to subscribers. These func- 
tions may be performed by a third party processor en- 
gaged in the business of providing such services to serv- 

10 ice providers and their subscribers, or by the provider 
itself or perhaps even by a large corporate subscriber. 

In the specific case of telephone billing, the bulk of 
the billing information used or supplied by a telecommu- 
nications carrier to the third-party processor for the pur- 

'5 pose of preparing customer bills would consist of tele- 
phone-call-detail records including a carrier-assigned 
customer identification code, the originating station 
number, the called station number, a billing code clas- 
sifying the type of call (e.g., night, evening or day), the 

20 length of the call, and the actual billed cost of the call 
according to the carrier's tariffs, volume discounts, and 
other billing plans. The carrier provides additional billing 
records to account for equ ipment rental charges, month- 
ly service fees, payments, adjustments, taxes, and any 

25 other items affecting the amount billed to the customer. 
According to the invention, the processor receives 
a subscriber's billing records from the carrier at a stage 
in the carrier's ordinary billing process after the carrier 
has posted to the subscriber's account all charges and 

30 credits, has performed all billing-related calculations for 
that subscriber, and is ready to print a paper bill. By se- 
lecting this specific stage of carrier bill processing from 
which to extract billing information, the invention en- 
sures that the information supplied on diskette will ex- 

35 actly correspond to that on the paper bill. 

Extensive processing is required to put the informa- 
tion received from a carrier into an optical form for use 
on a personal computer. According to the invention, this 
processing is divided into two stages. 

40 The first stage reformats data received from the car- 
rier, segregates the records pertaining to each subscrib- 
er, analyzes billing data for each subscriber to generate 
a variety of pre-processed summary reports and graphs, 
and organizes the data into a table format suitable for 

45 loading into the particular database system used to 
manage this data on the subscriber's personal compu- 
ter. In practice, since it is expected that the processor 
will receive a large number of records from carriers and 
the analysis performed on these records is extensive, 

50 this first stage of processing would be preferably per- 
formed on a mainframe-class computer, and is accord- 
ingly referred to hereafter as "mainframe processing." 

The second stage of processing receives the infor- 
mation processed by the first stage, compresses this in- 

55 formation into a more space-efficient format, for each 
subscriber writes this information on a diskette compat- 
ible with that subscriber's personal computer, and gen- 
erates quality-control information useful in managing 
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and tracking the production of diskette bills. These sec- 
ond-stage functions can be performed on a network of 
PC-class computers and is accordingly referred to here- 
after as "PC processing." 

Once diskette bills are produced in the *PC s 
Processing" system, the resulting diskettes are mailed 
to customers who may use PC-compatible software ac- 
cording to the invention (the "user application") to dis- 
play and analyze their bill. When the user receives the 
diskettes, the information thereon must be decom- io 
pressed and loaded into a PC database using facilities 
provided by a user application program according to the 
invention. This user application preferably uses com- 
mercially available database software, such as 
"RBASE", a popular database package available for 1$ 
IBM-PC-compatible computers, to manage the billing 
records received on diskette. Except for a small amount 
of historical information used for certain graphs and 
summary reports, the database can contain only one 
"bill" at any time. When a new bill is received, the pre- 20 
vtous bill may be archived to a non-database file (flat 
file) on the user's disk for convenient retrieval. The new 
bill then replaces the old bill in the user application da- 
tabase. 

When writing information into the database, the us- 2s 
er application employs commercially available software 
routines, such as RBASE -specific database interface 
routines. When reading information from the database, 
the user application either uses the commercially avail- 
able interface routines, or a set of proprietary tree traver- 30 
sal routines (disclosed in the Microfiche Appendix) 
which substantially improve retrieval efficiency when 
reading sorted data from keyed tables. Thus, while the 
user application stores information in a database ac- 
cording to the RBASE storage model, the RBASE pro- 35 
gram per se is not required. However, a customer who 
happens to own a copy of RBASE could use it to obtain 
information from the database in ways not provided by 
the user application. 

40 

BRIEF DESCRIPTION OF THE DRAWINGS 

These and other features of this invention will be 
best understood by reference to the following detailed 
description of a preferred embodiment of the invention, 4S 
taken in conjunction with the accompanying drawings, 
in which: 

Fig. 1 is a block diagram showing an overview of 
the data flow in a telephone billing system according so 
to the present invention; 

Fig. 2 is a block diagram showing an overview of 
the data flow in the "Mainframe Processing" seg- 
ment of the system of Fig. 1 ; 

Fig. 3 is a block diagram showing an overview of 55 
the data flow in the "PC processing" segment of the 
system of Fig. 1 ; 

Fig. 4 is a block diagram showing an overview of 



the data flow in the "User Application 1 segment of 
the system of Fig. 1; 

Fig. 5 is a flow chart of the "main processing sec- 
tion" for a first processing program designated 
TPSBO10 which is used in the "Mainframe 
Processing" segment of Fig. 2; 
Fig. 6 is a flow chart of the "initialization" section for 
the aforesaid first processing program used in the 
"Mainframe Processing" segment of Fig. 2; 
Fig. 7 is a flow chart of the "input data editing" sec- 
tion for the first processing program used in the 
"Mainframe Processing" segment of Fig. 2; 
Fig. 8 is a flow chart of the "call detail accumulation 1 
section for the first processing program used in the 
■Mainframe Processing" segment of Fig. 2; 
Fig. 9 is a flow chart of the "station number break 
processing" section for the first processing program 
used in the "Mainframe Processing 1 segment of Fig. 
2; 

Fig. 10 is a flow chart of the "customer break 
processing" section for the first processing program 
used in the "Mainframe Processing" segment of Fig. 

2; 

Fig. 1 1 is a flow chart of the 'end-of-file processing" 
section for the first processing program used in the 
"Mainframe Processing 1 segment of Fig. 2; 
Fig. 1 2 is a flow chart of the "main processing" sec- 
tion for a second processing program designated 
TPSB020 which is used in the "Mainframe Process- 
ing" segment of Fig. 2; 

Fig. 13 is a flow chart of the "initialization" section 
for the aforesaid second processing program used 
in the "Mainframe Processing" segment of Fig. 2; 
Fig. 14 is a flow chart of the "erroneous customer 
data rejection 1 section for the second processing 
program used in the •Mainframe Processing" seg- 
ment of Fig. 2; 

Fig. 1 5 is a flow chart of the "write PC transfer tape 
records" section for the second processing program 
used in the "Mainframe Processing* segment of Fig. 
2; 

Fig. 16 is a flowchart of the 'end-of-file processing" 
section for the second processing program used in 
the "Mainframe Processing" segment of Fig. 2; 
Fig. 1 7 is a flow chart of a program used in the "PC 
Processing" segment of Fig. 3 for reading a main- 
frame-produced tape; 

Fig. 18 is a flow chart of a program used in the "PC 
Processing 1 segment of Fig. 3 for loading billing da- 
ta onto PC-compatible diskettes; 
Fig. 1 9 is a flow chart of a program used in the B PC 
Processing" segment of Fig. 3 for creating a main- 
frame-readable export tape; 
Fig. 20 is a flow chart of the 'main-menu* section 
for a customer-service file maintenance program 
which can be used in the "PC Processing* network 
of Fig. 3; 

Fig. 21 is a flow chart of the "add new carrier" see- 
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tion for a customer-service file maintenance pro- 
gram of Fig. 20; 

Fig. 22 is a flow chart of the "edit existing carrier' 
section for the customer-service file maintenance 
program of Figs. 20 and 21 ; 
Fig. 23 is a flow chart of the "add new customer" 
section for the customer-service file maintenance 
program of Figs. 20-22; 

Fig. 24 is a flow chart of the "edit existing customer" 
section for the customer-service file maintenance 
program of Figs. 20-23; 

Fig. 25 is a flow chart of the "display errors" section 
for the customer-service file maintenance program 
of Figs. 20-24; 

Fig. 26 is a flow chart of the "display reports" section 
for the customer-service file maintenance program 
of Figs. 20-25; 

Fig. 27 is a flow chart of the "system maintenance" 
section for the customer-service file maintenance 
program of Figs. 20-26; 

Fig. 28 is a flow chart of the "main menu - section 
for the aforesaid "User Application" program of Fig. 
4; 

Fig. 29 is a flow chart of the "display billing inquiry" 
section for the "User Application " program of Fig. 4; 
Figs. 30A and 30B are flow charts of the "display 
call detail" subsection of the 'display billing inquiry" 
section for the "User Application" program of Fig. 4; 
Figs. 31 A and 31 B are flow charts of the 'display 
call summary" subsection of the "display billing in- 
quiry" section for the "User Application" program of 
Fig. 4; 

Fig. 32 is a flow chart of the "graph data" section for 
the "User Application" program of Fig. 4; 
Fig. 33 is a flow chart of the 'graph historical usage" 
subsection of the "graph data" section for the "User 
Application" program of Fig. 4; 
Fig. 34 is a flow chart of the 'graph hourly call dis- 
tribution" subsection of the "graph data" section for 
the "User Application Program" segment of Fig. 4; 
Fig. 35 is a flow chart of the "system utilities" section 
for the "User Application" program of Fig. 4; 
Fig. 36 is a flow chart of the "load new data' sub- 
section of the "system utilities" section for the "User 
Application Program* segment of Fig. 4; 

DETAILED DESCRIPTION OF THE PREFERRED 
EMBODIMENT 

Overall System Summary 

The mainframe processing aspect of the invention 
involves four major activities: a first sort, an editing and 
table accumulation program, a second sort, and transfer 
tape production program. The billing information may be 
received from one or more telecommunications carriers 
via magnetic tape, disk, or data communications lines 
(referred to hereafter for simplicity as 'billing tape' or 



simply 'tape'). The information is received in formats 
roughly corresponding to the logical record layouts ac- 
cording to which that information is stored in each car- 
rier's data processing facilities. Because this informa- 

5 tion will be obtained from the carrier as unstructured 
(flat-file) dumps of their accounting databases, records 
for a particular customer may appear in several files and 
consequently may be widely distributed along the tape. 
Therefore, in the first sort, the system first sorts all billing 

10 data received on the carrier tape by customer identifi- 
cation code and originating station number to group all 
records for a specific customer together. 

The editing and table accumulation program per- 
forms the bulk of the mainframe processing work. This 

is program handles the entire set of records received on 
the carrier tape in one pass, processing one record at a 
time. Since these records have been previously sorted 
by customer identification code and originating station 
number, each record is edit-checked to ensure that the 

20 appropriate type of data is contained in each field. Since 
the invention contemplates receiving billing information 
from multiple carriers, a generic internal record format 
is defined, to which each billing record received from 
various telecommunications carriers is converted ac- 

25 cording to a carrier-specific algorithm. For most records 
in the input stream (and particularly call-detail records), 
the editing and table accumulation program generates 
a corresponding output record in the generic format. In 
addition, this program accumulates data to produce for 

50 each customer a variety of precalculated summary re- 
ports and graphs which are included on the diskette bill 
and are thus available for display on the user's personal 
computer with minimal additional personal computer . 
processing. These include the following: 

35 

number of calls, length, and total call cost for each 
accounting or project code; 
number of calls, length, and total cost for day, 
evening and night calls for each carrier; 
40 - number of calls, length, and total cost of calls of 
each call type; 

number of calls, length, and total cost for day, 
evening, and night calls to each terminating area 
code; 

45 - number of calls, length, and total cost for calls of 
each product type (i.e. carrier's marketing plan); 
number of calls, length, and total cost for day, 
evening, and night calls from each site or location 
identifier 

50 - nurrtber of calls, length, and total cost for calls made 
from each originating station and authorization 
code; 

graphs showing historical usage by month; and 
graph showing number of calls made by hou r of the 
5S day. 

While these tables could be generated on the sub- 
scriber's personal computer by conventional methods 
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using information present in call-detail records without 
the mainframe preprocessing contemplated by this in- 
vention, this would require a time-consuming front-to- 
back scan of the entire contents of the database. By pre- 
processing these tables on a computer with greater 5 
processing and storage resources, the present inven- 
tion optimally makes the most commonly-needed re- 
ports and graphs immediately available upon the user's 
request, at the relatively modest expense of additional 
mainframe processing and additional PC database stor- 10 
age requirements. 

In order to pass the preprocessed report informa- 
tion along to the user's personal computer via the dis- 
kette bill, the editing and table accumulation program 
generates new information records in addition to those '5 
from the input stream which are merely edited and refor- 
matted. The ultimate target of the carrier-supplied billing 
information is a database located on the user's personal 
computer, which database is organized, at the logical 
level, into a number of tables. To permit subsequent 20 
processing steps to identify the information contained in 
records, each record which is outputted by the editing 
and table accumulation program has a record-type iden- 
tifier, specifying the particular database table to which 
the record belongs. 2s 

Two additional activities are performed during the 
mainframe processing segment to prepare the data for 
transfer to a "PC Processing" network. After the editing 
and table accumulation program has completed, sec- 
ond sorting step sorts the output file by customer iden- 30 
tification code and record-type identifier to place the 
records in an optimal order for creating diskette bills and 
for loading the information on the diskette into the data- 
base on the user's personal computer. At this point, a 
file exists on the "mainframe - computer in which, for 35 
each customer whose billing information appeared on 
the carrier billing tape, all records are grouped consec- 
utively, and among the records for a particular customer, 
all records of a specific type are grouped consecutively. 
A transfer tape production program adds control records 40 
expected by the "PC Processing" software at the begin- 
ning and end of this file, and surrounding the data for 
each carrier, customer, and table within the file. The out- 
put of the transfer tape production program is then writ- 
ten to a tape which will be transported to the "PC 
Processing" network. 

In order for the customer to display and further an- 
alyze this edited and preprocessed information using 
the customer's personal computer, it must be placed on 
PC-compatible diskettes. According to the invention, the so 
production of such diskettes is optimally performed us- 
ing a network of PC-class computers. The diskette pro- 
duction segment is therefore referred to as 'PC process- 
ing." 

The "PC Processing" network reads the tape con- ss 
taining mainframe-processed billing records, and for 
each customer represented thereon produces one or 
more diskettes compatible with the customer's personal 



computer and containing that customer's telephone bill 
information. The network is preferably implemented us- 
ing commercially available IBM Token-Ring hardware 
and Novelte network software. A Tape Controller PC 
(TCPC) with a disk drive and a 9-track tape drive is used 
to read the tapes produced by the mainframe. Two File 
Server PC's {FSPC's) with large disk drives temporarily 
store billing information read from mainframe tapes until 
diskette bills have been successfully prepared. Also 
stored on the FSPC's is a master database used to track 
tapes and diskette bills which have been prepared by 
the system. Several Loader Controller PCs (LCPC's), 
each controlling an automated diskette loader, manage 
production of diskette bills. The automated diskette 
loader includes a diskette drive connected to the LCPC 
and a mechanical arrangement controlled by the LCPC 
which can insert and remove diskettes without operator 
assistance. 

The "PC Processing" network operates under the 
control of several programs which manage the produc- 
tion of diskette bills. A transfer tape transcription pro- 
gram reads information from the mainframe-produced 
transfer tape. For each tape read, an entry identifying 
the tape is placed in the master database. For each cus- 
tomer found on the tape, the transfer tape transcription 
program Looks up the customer's record in the master 
database to determine which size and capacity diskette 
that customer requires. The transfer tape transcription 
program then determines which of the automated dis- 
kette loaders is capable of producing that diskette, and 
identifies the least busy loader. The transfer tape tran- 
scription program obtains the next available disk control 
number (DCN) (a tracking number uniquely and serially 
assigned to each set of diskettes produced by the sys- 
tem) from the master database. The transfer tape tran- 
scription program then copies all the data for the current 
customer from the tape onto a file server subdirectory 
assigned to the identified loader. The transfer tape tran- 
scription program makes a number of housekeeping en- 
tries in various database tables and begins processing 
the next customer's data from the mainframe tape. 

On each loader controller PC, an automated loader 
control program manages the actual production of dis- 
kette bills. The automated loader control program con- 
tinually examines the file server subdirectory assigned 
to the automated diskette loader it controls. When the 
automated loader control program finds a file in this sub- 
directory, it copies the file onto a disk in the loader con- 
troller PC, applying a data compression algorithm. Data 
compression reduces the number of diskettes which 
must be produced for customers with large numbers of 
call-detail records. In addition, compression enhances 
security, since without facilities provided by the user ap- 
plication on the customer's personal computer, the in- 
formation would be difficult to decode. The automated 
loader control program then copies the compressed da-, 
ta onto one or more diskettes, instructing the automated 
loader to insert and remove diskettes as required. When 



7 



13 EP0 541 

the automated loader control program finishes prepar- 
ing diskettes for a particular customer, it automatically 
examines its assigned file server subdirectory to deter- 
mine if files for additional customers are available. 

The master database on the 'PC processing" net- 5 
work maintains an inventory of tapes received, diskettes 
produced, and other customer-service related informa- 
tion. A package of inquiry and update programs is avail- 
able to customer service agents enabling them to main- 
tain and query this database. When new customers sub- 10 
scribe to the service, entries are made in the master da- 
tabase. An export tape production program extracts cer- 
tain customer information from this database (particu- 
larly the customer's carrier-assigned identification 
number and a separate customer ID assigned by the *5 
■processor*) to produce an export tape which may be 
sent to the mainframe computer to update customer da- 
tabases which may be stored thereon. 

Detailed System Description 

Fig. 1 is a data flow overview of a system in accord- 
ance with this invention for distributing PC-compatible 
diskette telephone bills to large-volume telecommunica- 
tions customers. In brief, telephone communications 
customers 24 wishing to receive diskette telephone bills 
subscribe for this service with their telephone carrier 1 0. 
Participating carriers 1 0 provide appropriately selected 
billing information 12 for such all participating subscrib- 
ers to a 'processor' company 13 which, according to 
one aspect of the invention, segregates the billing data 
by subscriber, performs a mainframe computer preproc- 
essing step 14 to produce a variety of in-depth billing 
analyses in the form of graphs and summary reports 1 6, 
and reorganizes both raw and analyzed billing data into 
an optimal format 1 8 for storage, manipulation, and dis- 
play on commonly available personal computers (re- 
ferred to herein as "PC's"). The processor 13 then per- 
forms a PC processing step 20 which writes this infor- 
mation onto one or more diskettes 22 which are com- 
patible with the subscriber's personal computer, and dis- 
tributes these diskettes to the subscribers 24. Then the 
subscriber, using an inexpensive personal computer 25 
and PC-compatible software according to another as- 
pect of the invention, can display and analyze a tele- 
phone bill with greater efficiency and flexibility than pos- 
sible using the conventional paper bill. By appropriately 
selecting the billing information 12 which is obtained 
from the subscriber's carrier, however, the invention pro- 
vides a telephone bill on diskette which is exactly rec- 
onciled with a standard paper bill supplied by the carrier. 

The PC aspect of the invention includes an applica- 
tion software package, capable of running on an IBM- 
PC-compatible computer 25 and capable (under the di- 
rection of the end user) of: 1) displaying the telephone 
bili or any portions of the telephone bill in its ordinary or 
paper bill format; 2) displaying the bill or selected por- 
tions of the bill sorted in a non-conventional order (for 
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example, call detail records sorted by length of call); 3) 
displaying a variety of pre-processed summary reports 
and graphs useful in analyzing the subscriber's telecom- 
munications costs; and 4) displaying non-preprocessed 
reports according to user-formulated ad-hoc query re- 
quests. 

But extensive processing is respired to put the in- 
formation 12 received from the carrier into an optimal 
form for use in a personal computer 25, and it is this 
processing which is carried out on the mainframe class 
computer 1 4. The steps of obtaining and rearranging ap- 
propriate billing information obtained from the carrier 1 0 
are outlined in Fig. 2, which is a block diagram showing 
an overview of the data flow in the "mainframe process- 
ing" segment 14 of Fig. 1. 

Mainframe Processing 

Fig. 2 illustrates a batch program in which billing in- 
20 formation from one or more telecommunications carri- 
ers 1 0 is received via magnetic media or telephone com- 
munications channels in formats roughly corresponding 
to the logical record layouts according to which the in- 
formation is presently stored in each carrier's data 
2S processing facilities. 

Appropriate data is selected from the carrier's account- 
ing databases and written to tape 46 in an unstructured, 
flat-file format. The invention contemplates that the 
records for any given communications customer will 
30 most likely appear in several files in a non-serial fashion 
and consequently will be widely distributed along the 
length cf the tape. Accordingly, a program TPSBO10 is 
responsible for retrieving the information from the tape 
and performing an extensive and complex mainframe 
35 processing procedure in order to reduce the information 
to a form which is sufficiently compact and compatible 
to be subsequently manipulated on a personal compu- 
ter 

The operation of Fig. 2 first performs a sort 48 on 
40 the entire input data from tape 46 to produce an inter- 
mediate file 50 containing the original information rear- 
ranged in customer number and station number order. 
In step 52 a number identifying the telecommunications 
carrier for which the bills ar to be produced is read. It is 
45 contemplated that this information will be retrieved from 
either an operator's console, an 80-column card, or any 
other suitable input device. The TBSBO10 program 
shown in step 54 edits and reformats the data into a for- 
mat that the target PC 25 can process. The processing 
so in step 54 contemplates that abort messages and other 
operator response or intervention can take place during 
processing as indicated by step 56. All edit error infor- 
mation and balance control information is compiled in a 
report 16 A, which is a portion of the report output 16 of 
55 Fig. 1 

As a result of processing step 54, records in a for- 
mat designated "PCdata," customer numbers with 
invalid data, and balance control information all move to 
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respective temporary storage files on respective data 
storage disks 1 , 2, and 3, as shown by steps 60, 68 and 
70. In addition to reformatting the original billing records, 
program TPSB010 accumulates summary reports and 
graphs for each customer and incorporates this data as 
additional records in file 60. Each record outputted by 
program TPSB010 includes a numeric record type iden- 
tifier. SORT 2 (step 62) reorganizes the records in inter- 
mediate file 60 by customer number and record type, 
placing the results into temporary file 64. For each cus- 
tomer, all records of a particular type are now grouped 
together. 

The data in temporary files 64, 68 and 70 is used 
by a second mainframe program known as TPSB020 as 
indicated by step 66. The latter is designed to convert 
the data into a PC-compatible data stream which is then 
stored on a 9-track tape medium in step 72. During the 
processing indicated in step 66 abort messages may be 
received as shown by step 74. On completion of the 
processing by program TBSB020 and writing of the final 
data to the 9-track tape, ail edit error information and 
balance control information is compiled as reports 16B, 
which corresponds to a portion of the reports indicated 
at 16 in Fig. 1. 

Attention is directed next to F:.g. 3 which is a block 
diagram overview of the data flow in the "PC processing" 
segment 20 of Fig. 1 . The PC processing system has a 
tape reader 78 which reads the 9-track tape that was 
prepared in step 72 of Fig. 2. The output of the tape read- 
er 78 is fed to a TCPC (Tape Controller PC) 80, which 
could be an IBM PC AT class machine, PS/2, or equiv- 
alent product having a 20-megabyte hard disk drive 81 . 
Upon reading the tape information the PC 80 drives 
printer 82 to prepare an identification label for each in- 
dividual customer diskette. The PC 80 also drives a sec- 
ond printer 84 which prepares mailing labels for the in- 
dividual customers' diskettes. 

PC 80 stores the data received from the reader 78 
on a local area network 83 which includes one or more 
FSPCs (file server PCs), such as a file server #1, des- 
ignated 84, and a file server #2. designated 86. This lo- 
cal area network may employ any standard local area 
network architecture appropriate for micro-class com- 
puters such as a ring, token ring, or other distributive 
area network system. It is also contemplated that this 
local area network will be driven by software commonly 
available for local area networks, such as that produced 
by such companies as Novelle and 3-Com. 

For each customer, billing records received from the 
PC 80 by the local area network are temporarily stored 
in a file on either file server #1 or file server #2, depend- 
ing upon a determination by PC 80 as to which server 
has fewer files waiting to be processed in its queue. At- 
tached to file server #1 is a personal computer labelled 
88. and a counterpart is attached to file server #2 des- 
ignated 90, which are both available for on-line handling 
of customer service inquiries and updating transactions 
as necessary. 



Each file server 84 and 86 transmits through the lo- 
cal area network individual customer information to be 
placed upon respective individual customer diskettes by 
one or more LCPC's (loader control PC's) which may be 
5 micro-class personal computers 92, 94, and 96 having 
respective 20-megabyte fixed disk drives 93, 95 and 97. 
Attached to each of these microcomputers are respec- 
tive 5 1/4" and 3 1/2" floppy diskette loaders 98, 106 and 
102 which transfer the individual customer information 
10 onto individual customer diskettes of the required size. 
This data is preferably stored on the floppy disks in a 
compressed format. 

Fig. 4 is a block diagram overview of the data flow 
in the "user application" segment 24 of Fig. 1 . The floppy 

f 5 diskettes 22 (see also Fig. 1 ) are those which were pro- 
duced on the loaders 98, 106 and 102 of Fig. 3. Each 
set of diskettes 22 constitutes an individual customer's 
telephone bill as supplied by the processor 1 3 of Fig. 1 , 
arranged in a particular manner that facilitates rapid ma- 

20 nipulation by the customer's personal computer running 
a user application program 105 according to this inven- 
tion, which has been previously supplied to the custom- 
er by the processor 13 or carrier 10 of Fig. 1. 

The user application program 105 includes a user 

& application database file 1 08. This file is maintained on 
a fixed disk in the user's personal computer and stores 
the information for a single telephone bill (i.e. a single 
month's billing for a single customer) for rapid and flex- 
ible information retrieval. The database file has a struc- 

30 ture compatible with a selected commercially available 
data base management system program, preferably a 
program widely sold under the name "RBASE." In step 
106. information from a new diskette bill 22 (which was 
compressed as described in the section discussing Fig. 

35 3) is restored to uncompressed form and loaded into the 
database file 1 08. Since the database file 1 08 may con- 
tain only a single month's bill (except for a small amount 
of historical trend information), each time a new diskette 
bill 22 is received, any previous bill in the database must 

40 first be removed. The user application program 105 will 
store such previous bills removed from the database file 
108 in non-database (i.e. "flat") archive files 110, which 
may be reloaded into the data base file 108 from time 
to time for further analysis. 

45 The user application program then performs a step 
112 which selects the appropriate data necessary to 
prepare reports of different types and extract specific in- 
formation from the available data base. The resulting re- 
ports my then be printed out as standard reports or ad 

so hoc inquiries 1 1 4, preprocessed reports 1 20, graphic re- 
ports 126 or a payment coupon for transmission along 
with payment of the bill to the telecommunications car- 
rier 1 0. The first three reports can also be written to stor- 
age files 116, 122 and 128, or displayed on the video 

55 screen of the customer's personal computer 25 as indi- 
cated at 118, 124 and 130 respectively. 
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TPSB010 

We now turn our attention to Fig. 5, which is a flow 
chart showing details of the main loop of the TPSB010 
program 54 used in the mainframe processing segment 5 
of Fig. 2, and Fig. 6 which is the initialization routine car- 
ried out before entering the main loop illustrated in Fig. 
5. 

Apart from branching to program junction P2 which 
jumps to other program routines discussed below, the 10 
initialization routine of Fig. 6 begins with step 1 78 where 
the program reads a carrier control data card 180 (or 
other information input device) identifying the telephone 
communications carrier whose individual customer 
records are currently being processed. Program step is 
182 then determines whether the carrier identification 
number is a valid carrier number. If the answer is nega- 
tive, then in step 184 the program advises the operator 
of a program abort condition. Then the operator will be 
required to perform some manual process (step 186) 20 
before the program aborts as indicated by step 188. If 
a valid carrier identification number is detected by the 
system at step 182, however, then in step 190 the cus- 
tomer information is read from an input file 192, which 
corresponds to the data file 50 of Fig. 2. 25 

The next step is 194, which detects an abnormal 
abort condition, i.e. no data at all in the, file. If step 194 
detects an end-of-file condition, then in step 196 the op- 
erator is notified of an abort condition, thus requiring a 
manual response 198 by the operator, after which the 30 
program is aborted at step 200. 

If an abnormal end-of-file condition is not detected 
at step 194, however, then a second end-of-file (EOF) 
test 194 is performed to detect a normal end-of-file con- 
dition, i.e., one which occurs at the conclusion of normal 35 
processing. The reason why test 194 only detects ab- 
normal end-file-conditions is because its input comes 
from step 1 90 at the beginning of an input record read. 
Test 1 95, in contrast, has a second input coming from 
program jump P8 in Fig. 5, which occurs repeatedly for *o 
each individual record. The affirmative output of step 
1 94, therefore, goes to jump point P3 leading to the end- 
of-file processing routine described bebw in connection 
with Fig. 11 . Conversely, the negative output of test 1 94 
goes to step 202 which will initialize the working storage 45 
space and set up the control fields for customer process- 
ing and proceed to program branch point A4 which en- 
ters the main loop of Fig. 5. 

At this point step 148 of the main program loop de- 
termines whether the program is continuing with the so 
same customer as on the previous processing cycle, or 
whether processing of that customer has been complet- 
ed and processing of a new customer started. It does 
this by determining whether the current customer ID 
number is or is not equal to the one processed by the 55 
previous processing cycle. If they are not equal, then a 
new customer is being processed and the program 
jumps at junction P4 to a customer break processing 



routine which continues at Fig. 10, aescribed below. 
Subsequently, the main loop of Fig. 5 is reentered at pro- 
gram junction A5. 

If the customer ID's are equal, however, then there 
is no customer break and the program proceeds in step 
1 54 to test whether there has been a change in the cur- 
rent customer's station ID number. If there has been a 
change, the program jumps at P5 to the station number 
break processing routine discussed below in connection 
with Fig. 9, and the main loop of Fig. 5 is reentered at 
junction A5. 

If the station number continues to be the same as 
on the last processing cycle, however, then the program 
jumps at branch point P7 to an input data editing routine 
discussed below in connection with Fig. 7. The main 
loop of Fig. 5 is then reentered at point A7, where pro- 
gram step 1 62 determines whether there are any errors. 
If there are, the program immediately goes to step 174, 
to read the next record from temporary file 50 (Fig. 2), 
and exits through a program jump P8 to the error detec- 
tion routine described above in connection with Fig. 6. 

If there are no editing errors, the program jumps to 
branch point P6 leading to the call detail accumulation 
routine of Fig. 8, discussed below, and the main loop of 
Fig. 5 is reentered at program point A6 leading to step 
170 which writes a call detail record (also referred to as 
■record type 4") to a file 60 on data storage disk 1 (Fig. 
2). The program also then goes on to perform step 174 
and jump to program point P8 as described above. 

We turn next to Fig. 7 for a detailed discussion of 
the "input data editing" section of "main frame process- 
ing" segment TPSBO10 of Fig. 2. The overall purpose 
of this step or process is to determine if an error condi- 
tion exists as to any of several factors reviewed in the 
customer's telephone information, and to produce the 
necessary operator reports and files as to any error con- 
ditions detected. 

Starting with program jump P7 from Fig. 5 described 
above, the first step 206 of this data edit process is a 
determination by the program of whether the customer 
identification number for the currently processed cus- 
tomer consists of only numeric values and of whether 
these values are greater than 0. If this determination is 
negative, then step 208 will notify the system operator 
that the program is aborting and that the program will 
be held frozen until the required operator response 210 
is received. Then the program will abort as indicated by 
step 212. Should the test of step 206 be affirmative, 
however, then the customer identification information is 
passed on to step 21 4 to determine if the telephone sta- 
tion number of the telephone call currently being proc- 
essed is numeric and has a greater value than 0. If not, 
then program step 216 will set an error switch. Then at 
step 21 8 a determination is made whether the telephone 
call duration information for the currently processed tel- 
ephone call is numeric and is greater than 0. If that con- 
dition is not true, then an error switch is set in step 220. 

In step 222 the program determines whether the 
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charge amount for the currently processed telephone 
call is numeric and greater than 0. Should that be false 
then an error switch is set by step 224. Should the 
charge amount be numeric and greater than 0 the cur- 
rently processed call information is then passed on to 5 
step 226 which determines if an error switch has been 
activated by any of the above-described steps 216, 220 
or 224. If so, the program invokes step 228 to create an 
error report which may be written directly to disk 2 as 
described above (step 68 of Fig. 2). The error report ere- 10 
ated by step 228 also is written by step 232 to another 
file on disk 1 which corresponds to step 60 of Fig. 2. In 
any case, the program then sends the currently proc- 
essed telephone call information on to program junction 
A7 which reenter it into the main loop data flow of Fig, 5. is 

For more information regarding the call detail infor- 
mation accumulation process of the "main frame 
processing' program of Fig. 2, we now turn to the flow 
chart of Fig. 8. This routine is entered at program jump 
point P6 coming from the main program loop of Fig. 5 20 
described above. The first step 238 accumulates the to- 
tal number of calls, their duration, and their charges ac- 
cording to a standard geographic breakdown known as 
"NPA." The next step 240 does the same accumulation, 
broken down by call types, i.e., evening, off-hour or day- 2s 
time full rate calls. The next step 242 does the same 
accumulation, broken down by customer station 
number. The information accumulated by steps 238, 
240 and 242 is then returned for processing via program 
jump A6 for reentry into the data flow of the main pro- 30 
gram loop of Fig. 5. 

For a more detailed understanding of the station 
number break routine we now turn to Fig. 9, which is a 
flow chart of the station number break processing sec- 
tion of the "mainframe processing" segment TPSBO10 35 
of Fig. 2. This routine is entered via program jump point 
P5 coming from the main loop of Fig. 5. In the first step 
246 a "statsum rec" or station summary record (also 
designated a record type 5) is created and written to out- 
put disk 1 , corresponding to step 60 of Fig. 2). This is a 40 
summary of total telephone usage in terms of the 
number of calls, call duration and charges, broken down 
by geographical area and call type, for a given customer 
calling station. This record is written to file 60 of Fig. 2. 
The next step 250 accumulates station sum records for 45 
all customer stations, broken down by call duration and 
charges, for the current customer. Then in step 252 the 
program resets the station accumulation fields and 
break fields to their initial values before going on the next 
station for the current customer. so 

We now come to Fig. 1 0 which is a flow chart of the 
customer break processing section of program 
TPSB01 0 used in the "mainframe processing" segment 
of Fig. 2. This routine is entered by way of program jump 
P4 from the main loop of Fig. 5. The program's first step 55 
258 prepares and writes a "carsum rec" or carrier sum 
record (also designated record type 3) which covers the 
same information as the "statsum rec" of Fig. 9 but con- 



tains the total figures for all telephone calls and their du- 
ration and charges for all customer stations for a given 
customer and a given telephone carrier. This informa- 
tion is then sent for on-line storage to a file on disk 1 , 
corresponding to step 60 in Fig. 2. Similarly, step 262 
prepares and writes to disk 1 (step 60 of Fig. 2) a "NPAs- 
um rec" or NPA summary record (also designated 
record type 7) which contains the same information bro- 
ken down geographically, e.g., by area code. The next 
step 264 prepares and writes to disk 1 (step 60 of Fig. 
2) a "codesum rec" or code summary record (also des- 
ignated record type 6) which contains the same infor- 
mation broken down by call type code, i.e., evening, off- 
hour or daytime full rate calls. 

The next step 268 prepares and writes a report 1 6 A 
(see also Fig. 2), containing customer detail balancing 
information. Next in step 272 the carrier totals are accu- 
mulated, broken down by calls, duration, and charges. 
Thereafter in step 274 the program resets the customer 
accumulation fields and customer break fields, after 
which the program jumps via junction A4 back to the 
main program loop of Fig. 5. 

We now refer to Fig. 11 which is a flow chart of the 
"end of the file processing* section for processing pro- 
gram TPSB010 used in the "mainframe processing" 
segment of Fig. 2. This routine starts with program jump 
P3 from the "end of file" test 1 94 of the initialization rou- 
tine of Fig. 6. It then proceeds with step 284 in which the 
program prepares and writes the information for a car- 
rier control record (also known as record type 1 ) to disk 
1 of Fig. 2, a procedure which corresponds to program 
step 60 of Fig. 2. Next step 288 prepares and writes a 
balance control record to disk 2 of Fig. 2, a procedure 
which corresponds to program step 68 of Fig. 2. Next 
step 292 writes a balancing report to file 16A of Fig. 2, 
which corresponds to a portion of report 16 in Fig. 1. 
Thereafter the entire job is terminated. 

TPSB020 

For details of the TPSB020 program portion of the 
main processing procedure illustrated in Fig. 2, we turn 
first to the flow chart of Fig. 1 2 which represents the main 
program loop, and the flow chart of Fig. 1 3 which repre- 
sents an initialization routine. The "initialization" proce- 
dure of Fig. 1 3 begins with step 320 which represents 
the reading of an information stream 321 consisting of 
information coming from files 64, 68 and 70 and infor- 
mation coming from file 60 after it has been sorted by 
step 62 in the mainframe processing program of Fig. 2. 
This conformation is then written to a temporary online 
storage file 322. In step 324 this information stream is 
tested to determine if an end-of-file condition is present. 
If it is present in step 326 the program immediately 
sends an abort signal which requires an operator re- 
sponse 328 to abort the system at step 330. 

If no end-of-file condition exists, the information 
stream is sent on to step 332 to test for the presence of 
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type one record, a carrier control record If a carrier con- 
trol record is not present the program at step 334 ceases 
execution and requires an operator response 336 which 
causes the system to abort at step 338. If the carrier 
control record is present, then the next step 340 is to set s 
up working storage and control fields, after which the 
program returns via program jump A12 to the main 
processing loop of Fig. 12, where it enters at program 
point P12. 

In the main loop of Fig. 1 2 the system first seeks to io 
determine at step 300 whether an end-of-file condition 
exists. If so, then there is a program jump A13 to pro- 
gram point P13 in the end-of-file processing routine of 
Fig. 16, described below. If an end-of-file condition is 
not encountered, then the input data stream 321 (see is 
Fig. 2) is read in step 308 and written to an online stor- 
age file in step 310 to be used by other portions of the 
processing system. Step 308 is also executed when the 
main loop of Fig. 12 is entered at program point P14 
coming from jump A14 of the 'write PC transmit tape' 20 
routine of Fig. 1 5, discussed below. After step 308 the 
program exits at point A15 and jumps to entry point P15 
of Fig. 14, to which we turn next. 

Fig. 1 4 is a flow chart of the "check customer error" 
routine of for the processing program TPSB020 used in 2s 
the 'mainframe processing' section of Fig. 2. Entry into 
the routine of Fig. 14 is at program point P15. The first 
program step 344 is used to test for an end-of-file con- 
dition. If such a condition is present the system must 
next determine at step 346 whether the customer 30 
number was contained on the customer error file 60 (see 
Figs. 2 and 7). If the answer is yes, then in step 348 that 
fact is printed in an edit error report 16B (see Fig. 2) 
which represents a portion of report 16 in Fig. 1. If the 
answer to test 346 is negative, or after the entry to error 35 
report 16B is made, this routine exits at point A12, and 
reenters the main loop of Fig. 12 at entry point P12. 

If the end-of-file test at step 344 is negative, the pro- 
gram must then determine at step 352 whether there is 
an error, but the error does not affect the customer ID 40 
number (i.e., the current customer number equals the 
correct customer number). If so, then the program at 
step 354 accumulated the duration and charges and the 
number of the customer's calls by reading the input file 
data stream 321 (step 356), writes that information to a 4$ 
temporary file 358, and exits at A16 to the program rou- 
tine of Fig. 15. 

If at step 352 there is an error and the currenf cus- 
tomer number is not equal to the correct customer 
number, then the system must determine at step 364 so 
whether the error customer number is greater than the 
correct customer number. If that condition is found, then 
the system must determine at step 366 whether the cus- 
tomer was on the error file. If the customer appears on 
the error file then the information is passed on to be re- 
ported on error report 1 6B mentioned above. Thereafter, 
or if the result of test 366 is negative, the program exits 
from this routine at A1 2 to reenter the main loop at P1 2 



in Fig. 12. 

If at step 364 there is an error and the current cus- 
tomer number is not greater than the correct customer 
number, then the system must determine at step 372 
whether the error customer number is less than the cor- 
rect customer number. If that condition is found, then at 
step 374 the error information from file 68 (Fig. 2) is read 
and written to a temporary file 376, after which the rou- 
tine exits at A12, reentering the main loop of Fig. 1 2 at 
P12. If the test performed in step 372 is negative, how- 
ever, the routine exits at A1 6 to enter the routine of Fig. 
15atPl6. 

Fig. 15 is a flowchart of the "write PC transmit tape" 
section for the TPSB020 processing program used in 
the "mainframe processing" segment of Fig. 2. It starts 
out at step 380 where the program determines whether 
the current record type being processed is the same 
record type as was previously cycled. If that condition is 
false then step 382 determines whether a "start" record 
exists. If so, then the program will write a PC "end" con- 
trol record to the file in step 384. In either case, it will 
next determine the corresponding record type in step 
386 and in the next step 388 write a "start" PC control 
record. 

In the event of a negative answer to test 380, or after 
the conclusion of step 388, step 390 then reads the 
record type of the current record. Steps 392, 400, 406, 
412, 418, 424 and 430 in turn then determine if the cur- 
rent record type is 1 , 2, 3, 4, 5, 6, or 7 respectively. If it 
is a record of type 1 , then step 394 writes a "carrier con- 
trol" record to be placed on the nine-track mainframe 
tape 72 which was discussed in connection with Fig. 2. 
Similarly, If it is a record of type 2, 3, 4, 5, 6, or 7, then 
steps 402, 408, 414, 420 426 and 432 respectively 
writes "customer control, carrsum, calldet, stats urn, 
codesum" and "NPAsum" records respectively to the 
nine-track mainframe tape 72. In each case, after the 
tape 72 is written to, the program routine in step 398 
accumulates the balancing totals and then exits via pro- 
gram jump A14 to entry point P12 of the main loop, Fig. 
12. 

Fig. 16 is a flow chart of the "end of file processing" 
section for the TPSB020 program used in the "main- 
frame processing" segment of Fig. 2. This routine is en- 
tered at program point P1 3 coming from jump point A1 3 
of the main loop, Fig. 1 2. At step 436 the program reads 
the balance information record 438 previously stored 
online in file 70 of Fig. 2. The program next determines 
in step 440 whether an end-of-file condition exists. If so, 
the program in step 442 will notify the operator of a pro- 
gram abort and hart execution until there is an operator 
response 444, after which the abort step 446 takes 
place. If the end-of-file test is negative, then a determi- 
nation must be made whether the accumulated totals 
are equal to the balance record totals. If not, then in step 
450 the program performs an abort sequence 450, 452, . 
454 similar to the previously described sequence 442, 
444, 446. 
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If the test at step 448 is affirmative, however, then 
the program's next step 456 is to add the PC end data 
characters onto the data stream records and write it onto 
the nine-track tape 72 of Fig. 2, after which the program 
terminates. 

PC Processing 

We now turn to the programs used in the 'PC 
processing" segment of Fig. 3 for the reading of a main- 
frame-produced tape. Fig. 17 is a flow chart of the PC 
processing system's first program, designated 
"SBPROC01 - read mainframe produced tape." This 
program begins at step 460 where it reads the output 
data tape 72 which was created in Fig. 2, and which con- 
tains the processed carrier telephone bill data. The pro- 
gram's next step 462 is to obtain the current tape 
number and log it to a tape control table. (At the same 
time, the tape creation date and time, the number of 
records on the tape, the number of customers on the 
tape and the carrier ID are logged to the tape control 
table at 462.) 

Next, in step 464 the system reads the "start cus- 
tomer* record which in itself is not the data but delimits 
the data belonging to a particular customer's billing in- 
formation. The system then goes on to determine if an 
end of tape condition exists in step 466. If such a con- 
dition does not exist then in step 468 the program 
searches for the customer number in a customer table 
(CustTab). The program then in step 470 determines the 
disk type (5 1/4" or 3 1/2") required for the particular cus- 
tomer by looking at the information in the aforesaid Cust- 
Tab tables. The program then in step 472 checks the 
Loadr Tab (loader table) to obtain a proper loader 
number for the required size of target diskette, thus 
choosing between 5 1/4" loaders 98 and 106 on the one 
hand and 3 1/2" loader 1 02 on the other hand. The pro- 
gram then in step 474 goes on to determine which loader 
(if there is a choice of two or more) has the smallest 
number of data files in its queue, and selects that one 
as a means of maintaining an even processing flow to 
the loaders. 

The program in step 476 then reads a system pa- 
rameters (SysParam) table to determine the next file 
control number (FCN), after which it updates the 
SysParam table. Afterward the program at step 476 cop- 
ies the customer data to the disk file. In step 480 the 
program then adds a record to update a file control table; 
and in step 482 it produces a summary report of the 
transactions just described. If required, at step 484 it 
produces an error report. The program then loops back 
and reenters the program sequence at the start custom- 
er reading step 464, and recycles. 

At step 466, if the determination is that there does 
exist an end-of-tape condition, then the program pro- 
ceeds in step 488 to update the tape control tables 
(TapCnTab) and in step 490 to produce a summary re- 
port. If required, in step 492 it produces an error report. 



At this point, the routine described in Fig. 17 ends. 

We now turn to Fig. 18 which is a flow chart of the 
program referred to as SBPROC02, the loader control 
program used in the "PC processing" segment of Fig. 3. 

5 This loader control program begins its processing in 
step 494 by reading a configuration file into its memory. 
This enables the system to determine what is online and 
what are the requirements of the individual customer 
diskettes are. The program in step 496 then checks the 

io appropriate subdirectory on the hard disk where the cus- 
tomer data file would be located, and performs a test 
498 to determine if there is such a data file. 

If the determination in step 498 is that the required 
data file does not exist, then the program loops infinitely 

'5 back to steps 496 and 498 until it finds that such a file 
exists to be processed. By the use of this infinite loop, 
the system can continually poll or check to see if a file 
to be processed has been entered into the appropriate 
subdirectory. 

20 if step 498 determines that such a file does exist, 
then the program in step 504 seeks out the oldest file in 
the appropriate directory, and in step 506 it reads and 
compresses that file and writes it to the local hard disk 
drive "C:V In step 508 it then gets the next available disk 

2S control number from the system parameters table 
(SysParam) so that it has the information necessary to 
format the target diskette in the appropriate manner. At 
the same time this operation updates the system param- 
eter table by incrementing the disk control number by 

30 one. 

The next program step 510 obtains a copy of the 
processing file created in step 506 above and copies 
that processing file to the disk loader in order to create 
the actual diskette data file. The program then at step 
512 prints the disk labels and mailing labels. The next 
step 514 in the operation obtains from the system pa- 
rameter (SysParam) tables the next available invoice 
control number and advises the system parameter table 
to increment the value by one. 

The program then at step 516 creates the appropri- 
ate invoice record and prints a paper invoice at step 518 
from which the customer can pay the telephone bill. 
Thereafter the program gets a disk control number 
(DCN) record (step 520), updates the fields of that 
record (step 522), and adds the record to a disk control 
(DC) table (step 524). It also updates the CustTab table 
mentioned previously (step 526), prepares a data disk 
summary report (step 528), and if necessary produces 
an error report (step 530). Thereafter the program loops 
back to reenter the subdirectory check step 496 and the 
described process is repeated as many times as neces- 
sary. 

Fig. 19 is a flow chart of a program designated 
SBROC03 used in the "PC processing' segment of Fig. 
3 for creating a mainframe-readable export tape. This is 
used by the mainframe processing system in updating 
its list of valid customers and producing the appropriate 
data streams for individual customer billing in future 
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processing cycles. The program begins at step 534 
where it reads the aforementioned system parameters 
(SysParam) table to determine what the next available 
export tape control (EXN) number is. It then obtains the 
next record from the aforementioned CustTab tables in $ 
step 536, reformats it and written to the export tape in 
step 538. 

The program next looks for an end-of-file condition 
in step 540 and if the condition does not exist, it loops 
back to step 536, to get the next CustTab record. If the "> 
end of file condition is affirmative, however, the program 
in step 544 updates the export tape control tables (Ex- 
pCnTab) and in step 546 it prints a summary report of 
the export tape processing. This terminates the export 
tape routine. '5 

PC Maintenance Program 

We now turn to a program for updating the end-user 
program as changes in service conditions may require. 20 
This program is operated on the computers 88 or 90 of 
the network of Fig. 3 by the processor company when- 
ever the needs of the telephone company or its sub- 
scribers require. 

Fig. 20 is a flow chart of the main-menu section for 2s 
the above-mentioned file maintenance program. The 
program is menu-driven, and the main menu display 548 
allows a determination of what areas the processor 
wishes to change. In steps 550, 558, 566, 574, 582 and 
592 the program determines whether the operator has so 
selected submenu 1 (the carrier menu), submenu 2 (the 
customer menu), submenu 3 (the error menu), submenu 
4 (the reports menu), submenu 5 (the system mainte- 
nance menu, or chooses to exit to DOS (the IBM per- 
sonal computer operating system), respectively- If none 3S 
of the above are selected, the program loops back to 
the start and continues to search for an operator selec- 
tion from the main menu. The submenu choices men- 
tioned above lead to program jump points 1 .0, 2.0, 3.0, 
4.0 and 5.0 respectively which are traced to their appro- 40 
priate program routines in the following discussion. 

Fig. 21 is a flow chart of the 'Add New Carrier' sec- 
tion for the file maintenance program. When the "Add 
New Carrier - submenu is invoked this routine is entered 
via program jump 1 .0 from Fig. 20. At that point step 596 45 
gives the operator the option of using the escape key 
on an IBM PC keyboard, and if that key is invoked then 
the operator is returned to the main menu of Fig. 20 as 
indicated at step 598. If the escape key is not invoked, 
then the operator instead may invoke the add-carrier so 
function key,, whereupon program step 600 which will 
produce a data entry display 602 on the video screen. 

If the operator inputs new information into the dis- 
play 602, the program will determine in step 606 if the 
new information has a proper carrier ID. If there already 55 
exists a carrier ID on file for the new carrier, then the 
system will display an error message 608 indicating that 
fact, and the program loops back to step 604 for reentry 



of the information. If there is no carrier ID on file as de- 
termined in step 606, then the program at step 610 will 
display a query message "Add Record to Carrier File?' 
If in response to that query message an escape key is 
actuated, th en at step 61 2 the program will return to sub- 
menu 1 . If, on the other hand, in response to the 'Add 
Record To Carrier File?" prompt, some other action is 
taken by the operator, the files will be updated accord- 
ingly. In addition, in step 616 the fields of the data entry 
form 604 will be cleared and the program will back to 
step 604 to accept further manual data input. 

If the operator selects some action other than the 
add carrier function in step 600, the program exits at 
point 1.2 to go to another routine illustrated in Fig. 22. 
The latter figure is a flow chart of the 'Edit Existing Car- 
rier" section for the file maintenance program. Another 
option 618 on the carrier submenu is editing the carrier 
information. If the operator chooses this option, the pro- 
gram in step 620 asks if the operator wishes to choose 
a carrier ID which is already on file. The program then 
determines in step 622 if the chosen carrier ID is in fact 
on file. If not, the program in step 624 will display an 
error message and loop back to step 620 to ask again 
if the operator wishes to use an old carrier ID. 

But if at step 622 it is determined that the selected 
carrier I D is already on file, then trie program in step 624 
displays the relevant carrier record, and at step 626 asks 
the operator for any changes to the carrier record. It then 
updates the carrier record in step 628. If the carrier is to 
be deleted, the program in step 630 queries the user, 
and upon receiving an affirmative answer, then in step 
632 it carries out the deletion and loops back to sub- 
menu 1 . If the result of step 630 is in the negative, indi- 
cating that the carrier is not to be deleted, the program 
will also return to submenu 1 . 

It the edit carrier query of stop 618 is answered in 
the negative, in step 634 the program will ask whether 
the operator wishes to browse through the carrier files. 
If the user responds negatively, then the user is returned 
directly to submenu 1. If the answer is affirmative, then 
the program in step 636 will display the information con- 
tained in the carrier file. When the operator finishes 
browsing through the carrier file, exit is to submenu 1 . 

Fig. 23 is a flow chart of the "Add New Customer" 
section of the file maintenance program used in the "PC 
Processing" network of Fig. 3. This routine is entered 
from program point 2.0, which represents a jump from 
program point 2.0 of Fig. 20. The first determination 
made by the system at step 638 is whether the operator 
wishes to exit the display customer menu. An affirmative 
answer, indicating by invoking the escape key, results 
in a return to the main menu (step 640). Should the op- 
erator choose to invoke some other key, then the "Add 
Customer" query is displayed in step 642. If the operator 
does not choose the 'Add Customer" option, then the 
program jumps at 2.2 to the 'Edit Existing Customer" 
section of the file maintenance program, which is dis- 
cussed below in connection with Fig. 24. 
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If the operator chooses the 'Add Customer" option 
offered in step 642, then the appropriate data entry form 
is displayed in step 646. Then is step 648 the system 
accepts the new information entered into the data form 
and in step 650 proceeds to check whether the new cus- 
tomer identification number is already on file. If so, then 
an error message is sent to the display in step 652 and 
the program loops back to step 648 to accept new data 
entry once again. If the new customer ID is not already 
on file, then the program will proceed in step 654 to add 
a record to the customer file. 

The program in step 656 then offers the operator an 
option to escape from the current submenu and return 
to submenu 2 in step 658 if the operator invokes the es- 
cape key. Otherwise, the program in step 660 will clear 
the fields on the data entry form and loop back to step 
648 for the acceptance of additional new customer in- 
formation. 

Fig. 24 is a flow chart of the "Edit Existing Customer" 
section for the customer service file maintenance pro- 
gram. It is entered through program jump 2.2 from Fig. 
23 just described. Where the operator invokes the "Edit 
Customer" option of the customer submenu offered in 
program step 662, then the program at step 664 accept 
new customer ID information. The new customer ID in- 
formation is then evaluated by the program at step 666 
and a determination is made as to whether there is al- 
ready such a customer ID on file. If there is, the appro- 
priate existing customer record is displayed at step 668. 
Then at step 670 the program accepts changes to the 
relevant customer record and at step 672 the record is 
updated. The program then returns to submenu 2 in step 
674. 

But if at step 666 the customer ID is found not to be 
on file, the program displays an error display message 
to that effect and the program then returns to step 664 
for the entry of valid new customer ID data. 

If at step 662 the operator does not select the edit 
customer option step 676 offers an option to browse 
through the customer information file 678 (step 678). Af- 
ter browsing is completed, or if the browse option is re- 
fused, the program exits to step 674 and redisplays sub- 
menu 2. 

Fig. 25 is a flow chart of the "Display Errors" section 
for the file maintenance program. It is entered through 
program jump 3.0 from Fig. 20 described above. The 
program first determines in step 680 if the operator wish- 
es to return to the main menu (step 682), a selection 
which is invoked by means of the escape key. If the op- 
erator chooses some other option, the program at step 
684 asks whether the operator wishes to update an error 
record. If the operator chooses to do so, then the user 
is presented by program step 686 with an opportunity to 
input an error entry control number The system then 
determines at step 688 if the error control number is on 
file. If it is, at step 690 the requested error record is dis- 
played. The program then at step 692 affords the oper- 
ator an opportunity to changes tc the error status. If such 



changes are made, then the program at step 694 up- 
dates the error record. At the end of the error record 
update, the program exits to submenu 3 in step 696. 
If in step 688 the determination is that there is no 
$ such control number on file, then an error message is 
displayed in step 698. The program then returns to step 
686 for correct entry of error control numbers. 

If the operator chooses not to update an error record 
in step 684, the operator is given an option in step 698 

io to invoke the browse function for the error file display. If 
that option is exercised, then in step 700 the error file 
display is actuated. Afterwards, or if the user does not 
choose, in step 698 to select the browse function, the 
program returns to submenu 3 in step 696. 

is Fig. 26 is a flow chart of the "Display Reports" sec- 
tion for the file maintenance program. The program is 
entered by program jump 4.0 from Fig. 20. In step 702 
it presents an option to exit to the main menu if the es- 
cape key is invoked. Otherwise the operator is present- 

20 ed in step 706 with an option to select the report of cus- 
tomers by cycle. If that function is invoked, then the pro- 
gram in step 708 will get the data from the customer file 
and print it out as a document 710. The program then 
returns to submenu 4 at step 712. 

25 |f the operator elects not to invoke the report of cus- 
tomers by cycle at step 706, then step 712 present the 
option of obtaining a report of customers with no usage. 
Should the operator invoke that function, the program 
at step 714 will get the data from the customer file and 

30 print out a customer report 71 6. The program will then 
go to submenu 4 in step 712. 

Should the report of customers with no usage func- 
tionality not be invoked in step 712, then the next menu 
option will be the report of unacknowledged errors in 

35 step 7 1 8. If the operator invokes that selection, then the 
program will at step 720 obtain the data fron the error 
file and in step 722 will print the unacknowledged error 
report. The program will then again return via step 712 
to submenu 4. 

40 Should the user not choose to invoke the report of 
unacknowledged errors in step 718, there is the remain- 
ing option of creating a report of unresolved errors in 
step 724. If that option is invoked, then the program in 
step 726 obtains the information from the error file, 

45 sends it to a printer to print an unresolved error report 
728, and then returns to submenu 4 in step 712. If none 
of the available functions are not invoked, then the pro- 
gram will return directly to submenu 4. 

Fig. 27 is a flow chart of the "System Maintenance" 

50 section of the file maintenance program. It is entered 
through program jump 5.0 from Fig. 2C. This module 
first presents an option in step 730 to return to the main 
menu by actuating the escape key. If the operator does 
not exercise that option, the other choice is presented 

55 at step 734 to delete inactive customers. If that option 
is chosen, then the program at step 736 will delete the 
inactive records from the customer file and at step 738 
will delete the associated records from the disk control 
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table (DiskCnTab), the fife control table (FileCnTab), and 
the invoice control tables (InvCnTab). In step 740 a re- 
port will then be printed of all of the deleted records. The 
program then returns to submenu 5 in step 742. 

If the operator chooses not to invoke the Delete In- 
active Customers function, there is a further option in 
step 744 of determining whether to perform a bad up of 
files. If that option is invoked, then the program in step 
746 performs the backup. After, or if that option is not 
chosen at step 744, the program returns to submenu 5 
at step 742. 

End-User Application Program 

We turn next to the 'User Application - program 
summarized in Fig. 4, i.e. the program which is run by 
the end-users (telephone customers) on their own per- 
sonal computers to analyze their telephone bills in ac- 
cordance with the capabilities of this invention. 

Fig. 28 is a flow chart of the "Main Menu' section 
for the user application program, which begins with a 
sign-on screen display 748 of the publisher's logo and 
copyright notice. The program then in step 750 fetches 
an initial message or startup screen or the like from an 
information file, and in step 752 displays it on the mon- 
itor. 

Ignoring for the moment a program entry point M, 
which will be discussed later, the program in step 756 
then displays the main menu of end-user choices. The 
first option available for selection on this menu level is 
a help key. If that key is invoked at step 758, then at step 
760 the program will display the main help screen for 
this segment of the end-user processing program, and 
then loop back to step 756. Should the end-user not in- 
voke the help key, the next possible selection, presented 
by step 762, is a billing inquiry. When this option is se- 
lected, the program will send the end-user to the billing 
inquiry submenu via program jump B which leads into 
Figs. 29-31 , discussed below. 

If the end-user should not choose the billing inquiry, 
the next choice available (step 766) is a graph data func- 
tion. If the end-user makes this choice, he or she will 
then be taken into the graph data menus of subsequent- 
ly discussed Figs. 32-34 via program jump B. 

Otherwise in step 770 the user may next select a 
system utilities option. If that selection is invoked, then 
the user application program will be taken to a system 
utility menu via program jump S leading to Figs 35 and 
36, discussed below. 

The next available selection is in step 774 which 
permits the user to exit to DOS, the operating system of 
the user's personal computer. If the user chooses to in- 
voke that selection, he will be taken into the operating 
system directly 776, and if the user chooses instead to 
invoke the escape key to reject all of the preceding 
choices, then in step 778 the program will also exit to 
the operating system. 

Figure 29 is the first of five flow charts dealing with 



the "Display Billing Inquiry - section for the "User Appli- 
cation" program of Figure 4. It is entered via program 
jump B from Fig. 28, and begins in step 780 with display 
of a billing inquiry menu. This menu offers the user the 
s choice of eight options: billing report, financial detail re- 
port, call detail report, call summary report, call summa- 
ry report, display special text, ad hoc inquiry, help, and 
escape; which are implemented by program steps 782, 
802, 806, 810, 818, 826 and 832 respectively. 

to The billing report option of step 782 and the financial 
detail report of step 784 are simitar in their operation, 
differing only as to what information is extracted from 
the available databases for billing and for financial de- 
tail. After the user chooses either of these options, the 

'5 program in step 786 reads from the system parameters 
(SysParam) file the currently selected output location (i. 
e., to the screen, to disk, to the serial port, to the parallel 
port) for the billing or financial detail report, and in step 
788 the program then displays the current output toca- 

20 tion to the screen. The program in step 790 will then ac- 
cepts any changes to the output location, and in step 
792 updates the current output location in the SysParam 
file to make that the new default output location. 

Depending on whether the selection of step 782 or 

2S that of step 784 was made, the program at step 794 will 
then get the appropriate report header information, from 
the SysParam file layout and the appropriate data from 
the revenue file for either the billing report or the finan- 
cial detail report. The appropriate information is then 

30 sent in step 798 to be printed (although if a disk file or 
the screen had been chosen as the output location in 
step 786 it would have been written to disk or to the mon- 
itor respectively). At the end of step 798 the program 
returns via program jump B to initial step 780 in order to 

35 redisplay the billing inquiry menu. 

If the call detail report is chosen at step 802, pro- 
gram jump B1 goes to the call detail menu of Fig. 30A, 
discussed below. Should the user select the call sum- 
mary report at step 806 then it takes jump 82 to the call 

40 summary menu of Fig. 31 A. 

Step 810 offers a special text option. As presently 
contemplated, there are three types of special text, but 
there could be any number. The purpose of the special 
texts is to provide the system with the same features as 

45 a written bill. Standard preambles or preliminary mes- 
sages may be added to the billing information in the 
same manner as they appear on paper bills. In addition, 
an epilogue might be added to the end of the bill text to 
advise customers of the late status of their account. Oth- 

so er types of material such as banners, headers, footers 
or textual material might also be added to make the bill 
more informative and flexible in the manner of a con- 
ventional bill. Such special information could be added 
to the bill by the individual subscriber upon request of 

55 the processor or the carrier. 

If the user selects the option of step 810, then in 
step 812 the program gets the special text from an in- 
formation file and in step 814 displays it on the screen. 
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Then the program returns via jump B to step 780 in order 
to redisplay the initial billing inquiry menu. 

When the user invokes the special ad hoc inquiry 
option of step 8 18, at step 820 the program gets the nec- 
essary records from the call detail (CallDet) file and in s 
step 822 it displays these records for browsing by the 
end-user at 822. Afterward, it returns via program jump 
B to step 780 to redisplay the billing inquiry menu. 

If the help function of step 820 is invoked, the pro- 
gram in step 828 will display the billing inquiry help "> 
screen, after which it again returns via program jump B 
to step 780 to redisplay the billing inquiry menu. 

The final selection from the billing inquiry menu is 
the escape key, whereupon step 832 return to the main 
menu of Fig. 28 via program jump M. is 

Figs. 30A and 30B are flow charts of the "Display 
Call Detail 1 subsection of the "Display Billing Inquiry" 
section for the "User Application" program of Figure 4. 
The segment represented by Fig. 30A is entered by way 
of program jump B1 from Fig. 29, previously discussed, 20 
and begins in program step 838 with display of a call 
detail menu. The options presented to the user by this 
menu include the report selection function of step 838. 
If the user actuates that function the program will take 
program jump B1 -2 to Fig. 30B. 2s 

Turning our attention now to that figure, program 
jump B1 -2 leads to step 840 which displays a report se- 
lection menu. Then at step 842 the program tests to de- 
termine whether one of the reports offered by that menu 
has been selected. If a report has not been selected and so 
the user invokes the escape key, the program step 844 
returns via program jump B1 to Fig. 30 A. 

If in step 842 the user should select a particular re- 
port, then step 846 the appropriate report header data 
is obtained from the SysParam file so that the report can as 
be properly formatted. The program their in step 848 ob- 
tains the current option and report number fron, a call 
data record selection (CDRS) file- The option number 
designates the type of report format requested by the 
user, and in particular designates how much of the avail- 40 
able information is to be included in the report. An option 
number of '1 ' specifies that all of the available informa- 
tion is to be put in a single file, white higher numbers 
specify that the report is to be broken into several small- 
er files. The report number is a numerical file name for 4S 
each of the file(s) containing the report which is to be 
written to disk. 

Accordingly, in step 850 the program tests whether 
the current option number is greater than 1 . If not, then 
all the available information is to be included in a single so 
file, and the program goes immediately to step 852 
where it sorts the call detail records. But if the option 
number is greater than 1 , then a plurality of files must 
be written to disk under distinct file names (report num- 
bers). In that case step 852 increments each previous 55 
report number by 1 and step 854 updates the current 
report number in the CDRS file so that numerically dis- 
tinct file names are assigned to each of the several re- 



port files which are written todisk. Thereafter in step 855 
the program reads the data selection criteria corre- 
sponding to the user's choice from the SysParam file, 
and in step 856 it selects from the call detail file the 
records designated by those criteria and sends them on 
for performance of the previously mentioned sort step 
852. 

After sort step 852, in step 857 the program gets 
the call detail report output location, i.e., monitor, printer, 
disk, etc. is determined from the system parameter file. 
Then, as before, the report is passed on to step 858 in 
which the system prints the call detail report to the des- 
ignated device (location). 

Returning now to Fig. 30 A, the negative branch of 
test 838 leads to program step 860 which tests whether 
the selection from the call detail menu of step 836 is the 
record selection. If so, the program in step 862 then gets 
the call detail record selection (CDRS) records and the 
current option number from the system parameter 
(SysParam) file. This information is then displayed on 
the screen in step 864, and in step 666 the program ac- 
cepts an changes the user chooses to make in the dis- 
played information. Finally, in step 868 the SysParam 
and CDRS files are updated and the program returns 
via jump B1 to the entry point of Fig. 30A. 

The report location menu option in step 870 permits 
the user to determine what device, i.e., monitor, screen, 
export file, printer, disk file, etc. should be the destina- 
tion of the report to be generated by this area of the pro- 
gram. If this optbn is chosen, then in step 872 the pro- 
gram gets the current call detail (CD) report location 
from the SysParam file, and in step 874 the program 
displays the current output location on the screen, and 
the user is prompted to make any changes. In program 
step 876 the program accepts any changes to the report 
output location, and in step 878 it updates the corre- 
sponding information in the call detail report output lo- 
cation records. The program then returns via jump B1 
to the display call detail menu at the entry point of Fig. 
30A. 

In program step 880 the user may select the help 
key. If the help key is selected, then in step 882 the call 
detail report help screen is displayed and the program 
then returns via jump B1 to the entry point of Fig. 30A. 

The last option available on the menu of Fig. 30 A is 
the selection of the escape key in step 884. Should that 
key be actuated the program returns via jump B to the 
entry point of Fig. 29. 

Figs. 31 A and 31 B are flow charts of the "Display 
Call Summary 11 subsection of the "Display Billing In- 
quiry" section for the "User Application' program of Fig. 
4. The segment illustrated in Fig. 31 A is entered via the 
B2 program jump which comes from Fig. 29, discussed 
above, and leads first to step 886 which displays a call 
summary menu. If the user actuates the call summary 
report selection from that menu in step 888, then the . 
program will exit via program jump B2-2 to Fig. 31 B 
where it performs step 890 to display a report selection 
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menu. If a report is selected from that menu, as deter- 
mined by step 892, then in step 894 the program gets 
the report header data from the system parameter file. 
Thereafter in step 896 it gets further information from 
the selected summary file, and in step 898 the program 5 
computes the report totals. Then in step 900 it gets the 
call summary output location from the SysParam file, 
and in step 902 prints the report to the designated loca- 
tion for printing or display or disk storage as determined 
from the system parameter file. At the end of that proc- 10 
ess the program returns to step 890 to redisplay the re- 
port selection menu. 

If in step 892 no report selection is made, and in- 
stead the escape key is actuated, the program exits via 
jump B2 to Fig. 31 A. 15 

Returning now to that figure, if the report selection 
menu is not selected in step 888, and the report location 
option is selected in step 906, then the program in step 
908 will get the current summary report output location 
(screen, printer or disk file) from the system parameter 20 
file, and in step 91 2 it will display that location to the user 
so that changes can be made. If such changes are 
made, then in step 914 the program proceeds to update 
the current summary report output location in the system 
parameter file. Having accomplished this, the program 2s 
returns via jump B2 to the entry point of Fig. 31 A in order 
to redisplay the call summary menu. 

The user has two other options on the menu of Fig. 
31 A, one of which is a help function selected in step 916. 
If that choice is made then in step 91 8 the call summary 30 
help screen is displayed. Upon leaving this submenu, 
the program returns to the via jump B2 to the call sum- 
mary menu step 886. 

The final selection available on this menu is the es- 
cape function, which in step 920 leave the call summary 35 
menu and moves back up to a higher level menu via 
program jump B, 

Fig. 32 is a flow chart of the "Graph Data" selection 
for the "User Application" program of Fig. 4. This routine 
is entered via program jump G from Fig. 28, and pro- *o 
ceeds to step 922 which displays the graph data menu. 
This menu has four choices represented by program 
steps 924, 926, 930 and 934. If the user chooses the 
help function of step 924, the graph data help screen 
will be displayed by step 925, after which the program 45 
1 returns to step 922 to redisplay the graph data menu. 

Among the user's other selectable options are his- 
torical usage (step 926), call distribution (step 930) and 
escape (step 934). If the historical usage function is se- 
lected by the user, the program branches via jumps point so 
G1 to Fig. 33. Similarly, if the user selects the call dis- 
tribution graph (step 930), the program exits via jump 
G2 Fig. 34. The last available alternative for the user on 
the graph data menu display is the escape key function 
(Rtep 934) which terminates the graph data menu dis- 55 
play and returns to the main menu via jump M. Figs. 33, 
34 and 35, to which these jumps lead, will now be dis- 
cussed. 



Fig. 33 is a flowchart of the "graph historical usage" 
section of the "graph data" portion of the "User Applica- 
tion" program of Fig. 4. It is entered via program jump 
G1 from Fig. 32, as discussed above, whereupon pro- 
gram step 938 displays the historical graph menu. From 
that menu the user may select the help function (step 
940) which will display the historical graph help screen. 
On the completion of a help screen session the user will 
be returned to the historical graph menu of step 938. 

Among the other choices on the historical graph 
menu are the total charges function of program step 
944. Once this step is actuated, the program at step 946 
will read the call charge (C11Chg) tables to obtain the 
appropriate data to fulfill the request for total charge in- 
formation graphs. The program then in step 948 com- 
putes the necessary graph values and determines the 
corresponding screen positions for graphic display. The 
graph thus computed then displayed on the monitor in 
step 950. At the close of the display graph session, the 
program returns to the historical graph menu of step 
938. 

The next two options available to the user from the 
historical graph menu include that of program step 952, 
a historical graph illustrating total usage, and that of the 
total DB/CR (total debit/credit records) function in pro- 
gram step 954, both of which cycle through the above- 
described steps 946, 948 and 950, returning then to step 
938, in the same manner as the total charges selection 
of program step 944. The DB/CR data relates exclusive- 
ly to non -call-detail records, such as leased phone lines, 
leased equipment, and the like; and is to be distin- 
guished fron the call detail information called for by 
steps 944 and 952. 

The remaining option in the program section of Fig. 
33 is the escape function, which in step 966 will termi- 
nate the historical graph menu session and exit via pro- 
gram jump G to the entry point of Fig. 32. 

Fig. 34 is a flow chart of the "Graph Hourly Call Dis- 
tribution" subsection of the "Graph Data" section for the 
"User Application Program" segment of Fig. 4. It is en- 
tered via program jump G2 from Fig. 32, and leads im- 
mediately to the call distribution graph of step 958. 
Should the user then actuate the help selection offered 
by program step 960, program step 962 will present a 
screen providing help for the Call Distribution Graph 
Function. After that help session is completed the pro- 
gram returns to the distribution graph menu step 958. 

If the user chooses the month alternative of step 
964, the program then will, in step 966, read from the 
call distribution file table (CaJIDist file) the necessary in- 
formation to produce the graph called for. Having ob- 
tained that information, the program in step 968 then 
processes the information to compute the necessary 
values for determining the graph's appearance on the 
screen, and in step 970 sends the results on to the dis- 
play device. At the termination of the graph display the 
program returns to the distribution graph menu of step 
958. 
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Should the user decide to display the weekly distri- 
bution graph of program step 972, the user must advise 
the system of what specific week of the current month 
is desired to be graphed (step 974). Similarly, should the 
user decide to display the daily distribution graph of pro- 5 
gram step 976, the user must advise the system of what 
specific day of the current month is desired to be graph- 
ed (step 977). After that is done, in both cases the pro- 
gram then cycles through previously described steps 
966, 968 and 970, to display the weekly or daily graphs io 
as the case may be, eventually returning to step 958 in 
the manner explained above. 

The remaining alternative for the user in this partic- 
ular menu is step 978, the escape function, which ter- 
minates the call distribution graph menu session, return- is 
ing via program jump G to Fig. 32. 

Fig. 35 is flow chart of the "System Utilities' section 
for the "User Application - program of Fig. 4. It is entered 
via program jump S from Fig. 28 described above, and 
goes immediately to a system utilities menu at step 980. 20 
Among the choices available from that menu is that of 
step 982, archiving the data of the current billing cycle. 
Should the user choose that particular option, in step 
984 a "working* message is displayed on the screen 
while step 986 is executed to archive all the inputted 2& 
data of the current billing cycle. When the archival 
processing job is completed, the program then returns 
via program jump S to step 980 in order to redisplay the 
system utilities menu. 

Among the other menu selections that are available 30 
to the user is the load new data function of step 988. 
When that option is selected, the program exits via jump 
S2 to a routine described below in connection with Fig. 
36. 

Next the user may choose (in step 990) to print the 35 
actual invoice. Upon selection of that particular menu 
item the invoice will actually be prepared and printed in 
step 992, after which the program executes jump S to 
return to the menu display function of step 980. 

Should the user choose the option of step 994, bill- 40 
ing information, the program in step 996 will display the 
billing information on the monitor, after which the pro- 
gram returns via jump S to step 980 to redisplay the sys- 
tem utilities menu. 

The next option is the help function 998 offered by 
step 998. Upon the actuation of that particular selection 
the program will in step 1000 display the system utility 
help screen and then return via jump S to the system 
utilities menu at step 980. 

The final alternative selection on this menu is the so 
escape key (step 1002). which terminates the system 
utilities menu session and returns to the next higher lev- 
el, the main menu of Fig. 28, via program jump M. 

Fig. 36 is a flow chart of the "Load New Data' sub- 
section of the "System Utilities" section for the 'User Ap- ss 
plication Program" segment of Fig. 4. It is entered via 
program jump S2 from Fig. 35, previously described, 
whereupon step 1006 will display a message advising 



the user that the program is being loaded. The system 
then in step 1008 opens an input file in which will be 
stored the new data to be loaded and an error file to 
track all associated error information. The program in 
step 1010 then writes the start date and time to a log 
file. The system then in step 1012 fetches from the input 
file an appropriate record which will subsequently be 
loaded into the database. 

After each such fetch operation the program exe- 
cutes a loop starting with a test 1014 to determine if the 
fetched data represents an end-of-file condition. If such 
a condition exists, the load procedure is completed, and 
accordingly the program in step 1016 will then close the 
database into which the data has been loaded. There- 
after, in step 1018 it will check the integrity of the newly 
created database file. And at the conclusion of the da- 
tabase integrity check, the program will end the loading 
data session and return to the system utilities menu via 
program jump S leading back to Fig. 35. 

If in step 1014, however, an end-of-file condition is 
not detected, then in step 1020 the program determines 
if an error has occurred. If so, in step 1 022 the error will 
be logged to the error file previously created in step 
1 008, and the program loops back to step 1 01 2 to fetch 
another record. 

The data coming from the source file is in a com- 
pressed form, as explained above. Therefore if the pro- 
gram does not encounter an error in step 1020, then in 
step 1024 it will use its decompression algorithm to ex- 
pand the fetched data to make it suitable for subsequent 
use by the R-base program, and only then will load the 
data to the target database table. 

During loading, the screen informs the user of the 
processing which is going on. In step 1026, therefore, 
after each record is expanded and loaded, the screen 
display is updated to reflect the processing just conclud- 
ed, and the program recycles back to step 1012, con- 
tinuing to do so until the end-of-file condition is detected 
by step 1020. 

CONCLUSION 

It will now be appreciated that the system of this in- 
vention provides a means for preparing on diskette tel- 
ecommunications or similar bills in an optimal format for 
further processing, display, and analysis under custom- 
er control on popularly -available, inexpensive personal 
computers. 

For each participating customer, the appropriately 
selected billing records are obtained from the telecom- 
munications carrier. In contrast to prior art systems, the 
system processes not only call detail records, but addi- 
tional billing records to account for equipment rental 
charges, monthly service fees, payments, adjustments, 
taxes, and any other items affecting the amount billed 
to the customer. In addition, all billing records are ob- 
tained from the carrier at a stage in the carrier's ordinary 
billing process after the carrier has posted to the sub- 
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scribe^s account all charges and credits, has performed 
all billing-related calculations for that subscriber, and is 
ready to print a paper bill. By selecting this specific stage 
of carrier bill processing from which to extract billing in- 
formation, the invention ensures that the information 
supplied on diskette will exactly correspond to that on 
the paper bill. 

Extensive preprocessing of these billing records is 
performed to place the records in a form compatible for 
use with inexpensive personal computers, and to pro- 
vide flexible, efficient access to the original records and 
to a variety of summary reports and graphs accumulated 
therefrom. In a first processing step, preferably per- 
formed on a large computer, the records are sorted, ed- 
ited and reformatted into an optimal organization for fur- 
ther processing on a personal computer. In addition, a 
variety of preprocessed summary reports and graphs 
are prepared for rapid retrieval on the customer's com- 
puter. By preprocessing these summary items on a com- 
puter with greater processing and storage resources, 
the invention optimally makes the most commonly- 
needed reports and graphs immediately available upon 
the user's request, at the relatively modest expense of 
additional mainframe processing and additional PC da- 
tabase storage requirements. In a second step, prefer- 
ably performed on a network of smaller computers, the 
reorganized records and summary reports for each cus- 
tomer are separated, compressed, and recorded on dis- 
kettes compatible with each customer's personal com- 
puter. 

A user application program according to the inven- 
tion on the customer's personal computer conveniently 
displays and analyzes the billing information supplied 
on diskette. The customer may retrieve the detailed bill- 
ing records in a variety of sorted orders, may select a 
subset of the records for further analysis, may view the 
preprocessed summary reports and graphs, and may 
prepare new summary reports on demand. Previous tel- 
ephone bills are kept in archive files for repeated anal- 
ysis. Billing information may be displayed on screen, 
printed on a printer, or written to an unstructured file for 
analysis beyond that provided by the user application. 

This system thus solves many of the disadvantages 
encountered in prior-art systems for collecting, process- 
ing and analyzing billing information under customer 
control. Diskette bills and the user application program 
are optimally compatible with popularfy available, inex- 
pensive personal computers, eliminating the need for 
customers to own or operate large, expensive comput- 
ers and software. The system provides to users billing 
information in computer-readable form, eliminating ex- 
pensive and error-prone data-entry and manual 
processing steps. The system processes complete bill- 
ing records and obtains these records from originating 
carriers at the proper stage to ensure that the diskette 
bills and analysis produced therefrom exactly corre- 
spond to the equivalent paper bills. 



Claims 

1 . A system for presenting information concerning the 
actual cost of a service provided to a user by a serv- 
5 ice provider, said system comprising: 



storage means for storing individual transaction 
records prepared by said service provider, said 
transaction records relating to individual serv- 
ice transactions for one or more service cus- 
tomers including said user, and the exact 
charges actually billed to said user by said serv- 
ice provider for each said service transaction; 
data processing means comprising respective 
computation hardware means and respective 
software programming means for directing the 
activities of said computation hardware means; 
means for transferring at least a part of said in- 
dividual transaction records from said storage 
means to said data processing means; 
a persona! computer data processing means; 
means for transferring said individual transac- 
tion records from said data processing means 
to said personal computer data processing 
means; 
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characterized in that: 

said data processing means generates pre- 
processed summary reports as specified by the 
user from said individual transaction records 
transferred from said storage means and or- 
ganizes said summary reports into a format for 
storage, manipulation and display on said per- 
sonal computer data processing means; 
said means for transferring said individual 
transaction records transfers said summary re- 
ports from said data processing means to said 
personal computer data processing means; 
and 

said personal computer data processing 
means is adapted to perform additional 
processing on said individual transaction 
records which have been at least in part pre- 
processed by said data processing means uti- 
lizing said summary reports for expedited re- 
trieval of data, to present a subset of said se- 
lected records including said exact charges ac- 
tually billed to said user. 

2. The system of claim 1, wherein said transaction 
records comprise telecommunication usage and 
cost information. 



55 3. The system of claim 1 , wherein said service provid- 
er is a telecommunication service provider. 

4. A method for presenting information on a personal 
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computer data processing means concerning the 
actual cost of a service provided to a user by a serv- 
ice provider, said method comprising: 

storing individual transaction records prepared 5 
by said service provider on a storage means, 
said transaction records relating to individual 
service transactions for at least one service 
customer including said user, and the exact 
charges actually billed to said user by said serv- 10 
ice provider for each said service transaction; 
transferring at least a part of said transaction 
records from said storage means to a data 
processing means; 

15 

characterized in that: 

preprocessed summary reports are generated 
as specified by the user from said individual 
transaction records transferred from said stor- 20 
age means and said summary reports are or- 
ganized into a format for storage, manipulation 
and display on a personal computer data 
processing means; 

said preprocessed individual transaction 2s 
records including said summary reports are 
transferred from said data processing means to 
at least one personal computer data processing 
means; 

additional processing of said individual trans- 30 
action records is performed on said at least one 
personal computer data processing means uti- 
lizing said summary reports for expedited re- 
trieval of data; and 

a subset of said individual transaction records 35 
chosen via said at least one personal computer 
data processing means is presented including 
said exact charges actually billed to said user. 

5. The method of claim 4, wherein said transaction 40 
records comprise telecommunication usage and 
cost information. 



Paten tan sprue he 45 

1 . System zur Darstellung von Information betreffend 
die Istkosten einer Dienstleistung, die einem Benut- 
zer durch einen Dienstleistungsanbieter zur Verfu- 
gung gestellt wird, wobei das System umfaGt: so 

eine Speichereinrichtung zum Speichem ein- 
zelner, durch den Dienstleistungsanbieter vor- 
bereiteter Transaktions-Aufzeichnungen, wo- 
bei sich diese auf einzelne Dtenst-Transaktio- 55 
nen fur einen oder mehrere Dienstleistungs- 
kunden einschlieftlich des Benutzers, sowie 
auf die dem Benutzer durch den Dienstlei- 



stungsanbieter pro Dienst-Transaktion tat- 
sachlich berechneten Kosten beziehen; 

eine Datenverarbeitungseinrichtung mit ent- 
sprechenden Kalkulations Hardware- E in rich- 
tungen und entsprechenden Software-Pro- 
grammierungseinrichtungen zur Steuerungder 
Aktivitaten der KalkulationsHardware-Einrich- 
tungen; 

eine Einrichtung zur Obertragung wenigstens 
eines Teiles der einzelnen Transaktions-Auf- 
zeichnungen von der Speichereinrichtung auf 
die Datenverarbeitungseinrichtung; 

eine PC-Datenverarbeitungseinrichtung; 

eine Einrichtung zur Obertragung einzelner 
Transaktions-Aufzeichnungen von der Daten- 
verarbeitungseinrichtung auf die PC -Datenver- 
arbeitungseinrichtung; 

dadurch gekennzelchnet, daft: 

die Datenverarbeitungseinrichtung nach Spe- 
zifizierung durch den Benutzer aus von der 
Speichereinrichtung ubertragenen einzelnen 
. Transaktions-Aufzeichnungen vorverarbeitete 
Sammelberichte erst el ft und die Sammelbe- 
richte in ein Format zur Speicherung, Verarbei- 
tung und Anzeige auf der PC-Datenverarbei- 
tungseinrichtung bringt; 

die Einrichtung zur Obertragung der einzelnen 
Transaktions-Aufzeichnungen die Sammelbe- 
richte von der Datenverarbeitungseinrichtung 
auf die PC-Datenverarbeitungseinrichtung 
Qbertragt; und 

die PC-Datenverarbeitungseinrichtung dazu 
ausgelegt ist, zusatzliche Bearbeitungen der 
einzelnen Transaktions-Aufzeichnungen 
durchzufuhren, die wenigstens zum Teil von 
der Datenverarbeitungseinrichtung vorverar- 
beitet wurden, die die Sammelberichte zum be- 
schleunigten Wiederauffinden von Daten ver- 
wendet, urn eine Untermenge der ausgewahl- 
ten Aufzeichnungen einschliefilich der dem Be- 
nutzer tatsacWich berechneten genauen Ko- 
sten darzustellen. 

2. System nach Anspruch 1, wobei die Transaktions- 
Aufzeichnungen die Telekommunikations-Nutzung 
und Kosteninformationen beinhalten. 

3. System nach Anspruch 1, wobei der Dienstlei- 
stungsanbieter ein Anbieter von Telekommunikati- 
ons-Diensten ist. 
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Verfahren zur Darstellung von Information auf einer 
PC-Datenverarbeitungseinrichtung betreffend die 
Istkosten einer einem Benutzer durch einen Dienst- 
leistungsanbieter zur Verfugung gestellten Dienst- 
leistung, wobei das Veriahren umfaRt: s 

Speichern einzelner durch den Dienstlei- 
stungsanbieter vorbereiteter Transaktions-Auf - 
zeichnungen auf einer Speichereinrichtung, 
wobei diese Transaktbns-Aufzeichnungen 10 
sich auf einzelne Dienst-Transaktionen fur we- 
nigstens einen Dienstteistungs-Kunden ein- 
schlie3lich des Benutzers sowie die genauen, 
dem Benutzer durch den Dienstleistungsanbie- 
ter fur jede Dienst-Transaktion tatsachlich be- is 
rechneten Kosten beziehen; 

Ubertragung wenigstens eines Teiles der 
Transaktions-Auf zeichnungen von der Spei- 
chereinrichtung auf die Datenverarbeitungs- 20 
Einrbhtung; 

dadurch gekennzelchnet, da (3: 

vorverarbeitete Sammelberichte nach Spezifi- 2s 
zierung durch den Benutzer aus von der Spei- 
chereinrichtung ubertragenen einzelnen 
Transaktions-Auf zeichnungen erstellt und die 
Sammelberichte in ein Format zur Speiche- 
rung, Verarbertung und Anzeige auf einer PC- 30 
Datenverarbeitungseinrichtung gebracht war- 
den; 

die vorverarbeiteten einzelnen Transaktions- 
Aufzeichnungen einschlieGlich der Sammelbe- 35 
richte von der Datenverarbeitungs-Einrichtung 
auf wenigstens eine PC-Datenverarbeitungs- 
einrichtung ubertragen werden; 

die einzelnen Transaktbns-Aufzeichnungen 40 
auf der wenigstens einen PC -Datenverarbei- 
tungseinrichtung zusatzlich verarbeitet wer- 
den, die die Sammelberichte fur das beschleu- 
nigte Wiederauffinden von Daten verwendet; 
und 45 

eine Untermenge von einzelnen, mittels der 
wenigstens einen PC-Datenverarbeitungsein- 
rbhtung ausgewahlten Transaktions-Aufzeteh- 
nungen einschliefclbh der dem Benutzer tat- so 
sachlbh berechneten genauen Kosten darge- 
stellt wird. 

Verfahren nach Anspruch 4, wobei die Transakt- 
ions-Aufzeichnungen die Telekommunikations- 55 
Nutzung und Kosten information umfassen. 



Revendieatione 

1. Systeme pour presenter des informations concer- 
nant le cout reel d'un service fourni a un utilisateur 
par un fournisseur de service, ledit systeme 
comportant : 

des moyens de memorisation pour mSmoriser 
des enregistrements de transaction individuelle 
prepares par ledit fournisseur de service, les- 
dits enregistrements de transaction concemant 
des transactions de service individuelles d'un 
ou plusieurs consommateurs de service y com- 
pris ledit utilisateur, et les charges exactes r6el- 
lement facturees audit utilisateur par ledit four- 
nisseur de service pour chaque dite transaction 
de service, 

des moyens de traitement de donndes compor- 
tant des moyens materiels de catcul respectifs 
et des moyens de programmation de logic ie I 
respectifs pour dinger les activity desdits 
moyens materiels de calcul, 
des moyens pour transferer au moins une par- 
tie desdits enregistrements de transaction indi- 
viduelle a parti r desdits moyens de memorisa- 
tion vers lesdits moyens de traitement de don- 
nees, 

des moyens de traitement de donnees par or- 
dinate ur personnel, 

des moyens pour transferer lesdits enregistre- 
ments de transaction individuelle a partir des- 
dits moyens de traitement de donnees vers les- 
dits moyens de traitement de donnees par or- 
dinateur personnel, 

caract6ris6 en ce que : 

lesdits moyens de traitement de donnees pro- 
duisent des rapports resumes pr6trait6s com- 
me specifie par ('utilisateur a partir desdits en- 
registrements de transaction individuelle trans- 
fers depuis lesdits moyens de memorisation 
et organ is ent lesdits rapports resumes en for- 
mat pour memorisation, manipulation et affi- 
chage sur les moyens de traitement de don- 
nees par ordinate ur personnel, 
lesdits moyens pour transferer lesdits enregis- 
trements de transaction individuelle transferent 
lesdits rapports resumes depuis lesdits 
moyens de traitement de donnees vers lesdits 
moyens de traitement de donnees par ordina- 
te ur personnel, et 

lesdits moyens de traitement de donnees par 
ordinateur personnel sont adaptes pour reali- 
se r un traitement supplemental sur lesdits 
enregistrements de transaction individuelle qui 
ont ete au moins en partie pr6trait6s par lesdits 
moyens de traitement de donnees utilisant les- 
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dits rapports r6sum6s pour recuperation acce- 
leree de donnees, pour presenter un sous-en- 
semble desdits enregistrements s6lectbnn6s 
comportant lesdltes charges exactes reelle- 
ment facturees audit utilisateur. s 

2. Systems selon la revendication 1 , dans lequel les- 
dits enregistrements de transaction comportent des 
informations d'utilisation et de coOt de telecommu- 
nications. 10 

3. Systeme selon la revendication 1 , dans lequel led it 
fournisseur de service est un fournisseur de service 
de telecommunications. 

15 

4. Precede pour presenter des informations sur des 
moyens de traitement de donn6es par ordinate ur 
personnel concernant le coGt reel d'un service four- 
ni a un utilisateur par un fournisseur de service, led it 
precede consistant a : 20 

memoriser sur des moyens de memorisation 
des enregistrements de transaction individuelle 
prepares par (edit fournisseur de service, les- 
dits enregistrements de transaction concernant 25 
des transactions de service individuelles pour 
au moins un consommateur de service y com- 
pris (edit utilisateur, et les charges exactes reel- 
lement facturees audit utilisateur par (edit four- 
nisseur de service pour chaque dite transaction 30 
de service, 

transferer au moins une partie desdits enregis- 
trements de transaction depuis tesdits moyens 
de memorisation vers des moyens de traite- 
ment de donnees 3S 



un sous-ensemble desdits enregistrements de 
transaction individuelle c hois is via lesdits au 
moins un moyen de traitement de donnees par 
ordinateur personnel est presente, comportant 
lesdites charges exactes r6ellement facturees, 
audit utilisateur. 

5. Precede selon la revendication 4, dans lequel les- 
dits enregistrements de transaction sont constitu6s 
d'informations d'utilisation et de coOt de telecom- 
munications. 



caracterise en ce que ; 



des rapports resumes pr6trait6s sont produits 
comma specifie par ('utilisateur a partir desdits to 
enregistrements de transaction individuelle 
transf6r6s depuis lesdits moyens de memori- 
sation et lesdits rapports resumes sont organi- 
ses en format pour memorisation, manipulation 
et affichage sur des moyens de traitement de 
donnees par ordinateur personnel, 
lesdits enregistrements de transaction indivi- 
duetle prdtrait6s comportant lesdits rapports 
resumes sont transfers depuis lesdits moyens 
de traitement de donnees vers au moins un so 
moyen de traitement de donnees par ordina- 
teur personnel, 

fe traitement supplemental desdits enregis- 
trements de transaction individuelle est realise 
sur lesdits au moins un moyen de traitement de ss 
donnees par ordinateur personnel utilisant les- 
dits rapports resumes pour recuperation acc6- 
leree de donnees, et 
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